|
Home > Archive > Linux Debian support > July 2007 > First jump into the AMD 64-bit world...
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
First jump into the AMD 64-bit world...
|
|
| Fredderic 2007-07-12, 1:13 pm |
| Greetings good peoples of the newsgroups...
Up until now, I've been using a relatively old Pentium4 based
computer. Nice and simple, nothing too fancy. But it's looking like
I'll have the opportunity shortly to step up to a somewhat more modern
dual-core AMD 64-bit system.
However, being pretty much clueless about anything other than the basic
simple single-core 32-bit Intel Pentiums, I'm wondering if someone can
share their experience with what changes I'll need to make, and what to
watch out for.
I still intend to have a mooch around google, but last time I listened
in on the AMD and SMP debates, I came away more confused than I
started. So knowing me I'll put in all the wrong search terms, and the
only results I'll find will be out-dated and good for little more than
confusing me even further. A response from someone here that I can use
to filter my impressions and misunderstandings would be mighty
helpful. 
Fredderic
| |
| sk8r-365 2007-07-12, 1:13 pm |
| Government satellites recorded Fredderic saying:
> Greetings good peoples of the newsgroups...
>
> Up until now, I've been using a relatively old Pentium4 based
> computer. Nice and simple, nothing too fancy. But it's looking like
> I'll have the opportunity shortly to step up to a somewhat more modern
> dual-core AMD 64-bit system.
>
> However, being pretty much clueless about anything other than the basic
> simple single-core 32-bit Intel Pentiums, I'm wondering if someone can
> share their experience with what changes I'll need to make, and what to
> watch out for.
<snip>
You'll probably be disappointed by my brevity, none the less, as an
home user on a 64bit ASUS, here's what I think: get it, put a 32bit
OS on and don't worry about the hype. 64bit is only very useful if
you're a huge number crunching kinda guy.
--
sk8r-365
http://goodbye-microsoft.com/
| |
| Fredderic 2007-07-12, 1:13 pm |
| On Thu, 12 Jul 2007 07:57:09 -0600,
sk8r-365 <sk8r-365@sk8r.debian.etch.invalid.org> wrote:
> Government satellites recorded Fredderic saying:
> You'll probably be disappointed by my brevity, none the less, as an
> home user on a 64bit ASUS, here's what I think: get it, put a 32bit
> OS on and don't worry about the hype. 64bit is only very useful if
> you're a huge number crunching kinda guy.
Okay, so you're saying to just install the 686 kernel builds on it like
I do now, and it'll work...?
Hmmm..... Thanks for that...
In that case, I'll probably slap on what I'm used to to get the system
up and going, and look at the amd64 architecture at a later date.
Fredderic
| |
| sk8r-365 2007-07-12, 1:13 pm |
| Government satellites recorded Fredderic saying:
> On Thu, 12 Jul 2007 07:57:09 -0600,
> sk8r-365 <sk8r-365@sk8r.debian.etch.invalid.org> wrote:
>
> Okay, so you're saying to just install the 686 kernel builds on it like
> I do now, and it'll work...?
Oh yeah. Read this:
uname -a
Linux sk8r 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux
cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 44
model name : AMD Sempron(tm) Processor 3000+
stepping : 2
cpu MHz : 1808.786
cache size : 128 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
bogomips : 3619.95
>
> Hmmm..... Thanks for that...
>
> In that case, I'll probably slap on what I'm used to to get the system
> up and going, and look at the amd64 architecture at a later date.
Debian Etch works like a charm and all my (old) 32bit apps like Q3A
run beautifully. Plus, support for things like flash, and others,
aren't fully 64bit supported as yet.
--
sk8r-365
http://goodbye-microsoft.com/
| |
| jellybean stonerfish 2007-07-12, 1:13 pm |
| On Fri, 13 Jul 2007 00:52:07 +1000, Fredderic wrote:
> On Thu, 12 Jul 2007 07:57:09 -0600,
> sk8r-365 <sk8r-365@sk8r.debian.etch.invalid.org> wrote:
>
>
> Okay, so you're saying to just install the 686 kernel builds on it like
> I do now, and it'll work...?
>
> Hmmm..... Thanks for that...
>
> In that case, I'll probably slap on what I'm used to to get the system
> up and going, and look at the amd64 architecture at a later date.
>
>
> Fredderic
I use 64 bit myself. The only thing that doesn't work is flash. There is
a way to make it work, but I haven't gone through the trouble.
stonerfish
| |
| sk8r-365 2007-07-12, 1:13 pm |
| Government satellites recorded jellybean stonerfish saying:
> On Fri, 13 Jul 2007 00:52:07 +1000, Fredderic wrote:
>
>
> I use 64 bit myself. The only thing that doesn't work is flash. There is
> a way to make it work, but I haven't gone through the trouble.
>
I have flash working (for my wife) but I could care less.
Regarding 64bit: what increased benefit did you find over 32bit?
Can you play 32bit games without chroot? If you use it, does OOo
calc and USB printing function correctly now? What of Abiword, too?
--
sk8r-365
http://goodbye-microsoft.com/
| |
| Harold 2007-07-12, 1:13 pm |
| On Thu, 12 Jul 2007 23:36:40 +1000, Fredderic wrote:
> Greetings good peoples of the newsgroups...
>
> Up until now, I've been using a relatively old Pentium4 based computer.
> Nice and simple, nothing too fancy. But it's looking like I'll have the
> opportunity shortly to step up to a somewhat more modern dual-core AMD
> 64-bit system.
>
> However, being pretty much clueless about anything other than the basic
> simple single-core 32-bit Intel Pentiums, I'm wondering if someone can
> share their experience with what changes I'll need to make, and what to
> watch out for.
>
> I still intend to have a mooch around google, but last time I listened
> in on the AMD and SMP debates, I came away more confused than I started.
> So knowing me I'll put in all the wrong search terms, and the only
> results I'll find will be out-dated and good for little more than
> confusing me even further. A response from someone here that I can use
> to filter my impressions and misunderstandings would be mighty helpful.
>
>
>
> Fredderic
Irecently moved up to an AMD x2 64 6000 running Fedora 7 X86_64. The only
real problem so far is no Adobe Flash. Everything else is fine. With
Firefox 2.004, Evolution 2.10.2, Pan 0.131 all open for a long time takes
about 600 MB. The system is much faster than what I replaced, as it
should be.
Harold
| |
| sk8r-365 2007-07-12, 1:13 pm |
| Government satellites recorded Harold saying:
>
<snip>
> The system is much faster than what I replaced, as it
> should be.
Are you saying the system is faster with the 32 vs. 64 bit OS on
the same machine or that this machine is faster than the old one it
replaced?
--
sk8r-365
http://goodbye-microsoft.com/
| |
| Burkhard Ott 2007-07-12, 1:13 pm |
| Am Thu, 12 Jul 2007 09:39:00 -0600 schrieb sk8r-365:
> Regarding 64bit: what increased benefit did you find over 32bit?
> Can you play 32bit games without chroot? If you use it, does OOo
> calc and USB printing function correctly now? What of Abiword, too?
Put more than 1 GB into the box an you see and feel the difference, if you
have an 64 bit system you should use the features (e.g. RAM access etc.)
| |
| jellybean stonerfish 2007-07-12, 7:13 pm |
| On Thu, 12 Jul 2007 09:39:00 -0600, sk8r-365 wrote:
> Government satellites recorded jellybean stonerfish saying:
>
> I have flash working (for my wife) but I could care less.
>
> Regarding 64bit: what increased benefit did you find over 32bit?
No benefit that I notice. I use 64 because my processor is 64.
> Can you play 32bit games without chroot?
This box is 64bit ubuntu. The games on the repositories work ( most of the
ones I tested, but the only ones I play are frozen-bubble, supper-tux and
tux-racer. I have installed a 32bit binary game (wolfenstein enemy
territory) and it works when my kids use it.
> If you use it, does OOo
> calc and USB printing function correctly now? What of Abiword, too?
I don't know what OOo calc is. I don't have a printer, but scanner,
camera and ipod all work. I use open office for formatted text or
spreadsheet as I don't have abiword installed.
stonerfish
| |
| Fredderic 2007-07-13, 1:14 am |
| On Thu, 12 Jul 2007 19:02:15 GMT,
jellybean stonerfish <stonerfish@geocities.com> wrote:
> On Thu, 12 Jul 2007 09:39:00 -0600, sk8r-365 wrote:
>
> This box is 64bit ubuntu. The games on the repositories work ( most
> of the ones I tested, but the only ones I play are frozen-bubble,
> supper-tux and tux-racer. I have installed a 32bit binary game
> (wolfenstein enemy territory) and it works when my kids use it.
>
> I don't know what OOo calc is. I don't have a printer, but scanner,
> camera and ipod all work. I use open office for formatted text or
> spreadsheet as I don't have abiword installed.
Sounds like I should just jump in with amd64, then...
Although... I am curious about how it goes with odd drivers. Things
like web cams, that are hard enough finding one that'll work in
Windoze, let along Linux, as it is. My wife's about to palm off an old
cheapo web cam on me (which is only fair, I palm my old computers off
on her ;) ), which I want to stick in the front window so I can see
who's coming up my driveway (it'll be useless at night, but such is
life). So I guess I'm asking whether there's a comparison anywhere of
what drivers do and don't work (I didn't find one myself, and no
one's suggested one yet, so I'm guessing there's no such thing, but
thought I'd ask anyhow).
Anyhow, if it's all good, then there's a new question or two, but I'll
save that for a new thread.
Fredderic
| |
| sk8r-365 2007-07-13, 1:14 am |
| Government satellites recorded Burkhard Ott saying:
> Put more than 1 GB into the box an you see and feel the difference, if you
> have an 64 bit system you should use the features (e.g. RAM access etc.)
Thanks for replying, but I have a Gig now and swap in use is less than half
(434360k in use). Why would I expect a benefit by adding more?
--
sk8r-365
http://goodbye-microsoft.com/
| |
| sk8r-365 2007-07-13, 1:14 am |
| Government satellites recorded jellybean stonerfish saying:
> On Thu, 12 Jul 2007 09:39:00 -0600, sk8r-365 wrote:
>
> No benefit that I notice. I use 64 because my processor is 64.
That's the experience I had.
>
> This box is 64bit ubuntu. The games on the repositories work ( most of the
> ones I tested, but the only ones I play are frozen-bubble, supper-tux and
> tux-racer. I have installed a 32bit binary game (wolfenstein enemy
> territory) and it works when my kids use it.
>
Would that be the i32-libs?
>
> I don't know what OOo calc is. I don't have a printer, but scanner,
> camera and ipod all work. I use open office for formatted text or
> spreadsheet as I don't have abiword installed.
Sorry, 'OOo' is OpenOffice.org abd 'calc' is their spreadsheet. I
use it for my pay check - time card.
I might *someday* switch to 64bit OS, only if I can still play
Q3A/UT2004, just because I can but not due to the belief it speeds up
anything. Reason I got the 64bit system is because that's all there
was available here in the middle of fly over country - Wyoming, USA.
--
sk8r-365
http://goodbye-microsoft.com/
| |
| sk8r-365 2007-07-13, 1:14 am |
| Government satellites recorded Fredderic saying:
<snip>
>
> Although... I am curious about how it goes with odd drivers. Things
> like web cams, that are hard enough finding one that'll work in
> Windoze, let along Linux, as it is.
Just search the web for the make and model of the cam for Linux
support (compatibility) ... most are supported. Pick whatever Linux
software package you prefer from there. It's generally *much*
easier to set up devices in Linux than on a Winbox.
<snip>
>
> Anyhow, if it's all good, then there's a new question or two, but I'll
> save that for a new thread.
Good luck and see ya then !
--
sk8r-365
http://goodbye-microsoft.com/
| |
| Burkhard Ott 2007-07-13, 7:14 am |
| Am Thu, 12 Jul 2007 21:11:57 -0600 schrieb sk8r-365:
> Government satellites recorded Burkhard Ott saying:
>
>
> Thanks for replying, but I have a Gig now and swap in use is less than half
> (434360k in use). Why would I expect a benefit by adding more?
>
You don't understand correctely, on a x86_64 your bus has more 'wires',
that means higher data throuput, the main memory isn't split in a lower
part and a higher part etc.
x86_64 was only the logical step, even the dual and quad core technology
cheers
| |
| Burkhard Ott 2007-07-13, 7:14 am |
| Am Thu, 12 Jul 2007 21:23:37 -0600 schrieb sk8r-365:
> Government satellites recorded jellybean stonerfish saying:
>
>
> That's the experience I had.
You can make this experience with compiling large software, you can make
the experience with databases, with webservers etc.
Unfortunately I can play with those stuff only at work, for home use I
still have a 32 bit system.
> Would that be the i32-libs?
That's one idea of x86_64, you can also use software which has been
compiled for 32 bit.
> I might *someday* switch to 64bit OS, only if I can still play
> Q3A/UT2004, just because I can but not due to the belief it speeds up
> anything. Reason I got the 64bit system is because that's all there
> was available here in the middle of fly over country - Wyoming, USA.
Install ia32-libs (debian packagename I don't use ubuntu) and all you 32
bit applications run in the 64 bit OS either.
cheers
| |
| Anton Ertl 2007-07-13, 7:14 am |
| Burkhard Ott <b.ott@derith.de> writes:
>You don't understand correctely, on a x86_64 your bus has more 'wires',
>that means higher data throuput,
The bus to main memory and to the L2 cache has the same number of
wires, and all of them are utilised. The data throughput is pretty
much the same, with some rare exceptions:
- If the application is memory or cache bandwidth limited and uses lots of
pointers, the 32-bit version will be faster, because the same
bandwidth transfers twice as many pointers per time unit.
- If the program does 64-bit integer computations, the 64-bit
version will be faster.
- x86-64 has more registers and a different calling convention, which
make it a little faster in many cases.
- x86-64 is guaranteed to have SSE2, which can be used to make some
programs more efficient (I guess that's the reason why oggenc runs
faster by about a factor of 1.4 in the 64-bit version).
> the main memory isn't split in a lower
>part and a higher part etc.
Unkless you are spending a lot of time in system calls, that does not
matter. If it does, you can run a 64-bit kernel (which eliminates
this problem) with a 32-bit userland.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
| |
| Anton Ertl 2007-07-13, 7:14 am |
| sk8r-365 <sk8r-365@sk8r.debian.etch.invalid.org> writes:
>I might *someday* switch to 64bit OS, only if I can still play
>Q3A/UT2004
UT2004 has fully supported 64-bit Linux from day one. However, once
you install the patch, the patch installs a 32-bit binary instead of
the 64-bit binary, and as a consequence UT2004 no longer works (at
least on Debian Etch); that's relatively easy to fix by finding the
64-bit binary that also comes with the patch, and installing it
instead of the 32-bit binary.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
| |
| Burkhard Ott 2007-07-13, 1:13 pm |
| Am Fri, 13 Jul 2007 09:38:36 +0000 schrieb Anton Ertl:
> Burkhard Ott <b.ott@derith.de> writes:
> The bus to main memory and to the L2 cache has the same number of
> wires, and all of them are utilised. The data throughput is pretty
> much the same, with some rare exceptions:
I don't agree as closer you are at the cpu as higher is your clock rate,
more clock rate more data transfer.
There has been the first idea to getting faster processors so we got the 3
GHz.
L2 is faster than ram -> higher clockrate
> - x86-64 has more registers and a different calling convention, which
> make it a little faster in many cases.
Not only more, the are more broadly either
cheers
| |
| Anton Ertl 2007-07-13, 1:13 pm |
| Burkhard Ott <b.ott@derith.de> writes:
>Am Fri, 13 Jul 2007 09:38:36 +0000 schrieb Anton Ertl:
>
>
>
>I don't agree as closer you are at the cpu as higher is your clock rate,
>more clock rate more data transfer.
But the maximum throughput does not change with whether you are using
the processor for 32-bit or for 64-bit programs.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
| |
| sk8r-365 2007-07-13, 7:13 pm |
| Government satellites recorded Burkhard Ott saying:
> Am Thu, 12 Jul 2007 21:11:57 -0600 schrieb sk8r-365:
>
>
> You don't understand correctely, on a x86_64 your bus has more 'wires',
> that means higher data throuput, the main memory isn't split in a lower
> part and a higher part etc.
> x86_64 was only the logical step, even the dual and quad core technology
>
Evidently. I *still* don't get it. I have a GIG of RAM on a 32bit OS with a
64bit machine (hardware) and there's less than 1/2 of that RAM currently
in use. So I see no reason to think by adding another GIG I'll have more RAM
in use. Rather, I should have a GIG and half unused then as opposed
to having a half GIG unused now. What I'm taking away from this is
you think - an analogy coming - that if I have a car which gets 30
MPG and the car has 10 gallon gas tank, if I put on a 20 gallon gas
tank, I should get better MPG.
--
sk8r-365
http://goodbye-microsoft.com/
| |
| Rockinghorse Winner 2007-07-13, 7:13 pm |
| On 2007-07-12, jellybean stonerfish <stonerfish@geocities.com> wrote:
>
> This box is 64bit ubuntu. The games on the repositories work ( most of the
> ones I tested, but the only ones I play are frozen-bubble, supper-tux and
> tux-racer. I have installed a 32bit binary game (wolfenstein enemy
> territory) and it works when my kids use it.
>
Can you install 32 bit Ubuntu on a 64 bit processor machine? I want all the
compatibility of 32 bit apps, but most of the good deals on computers
include AMD 64 bit chips.
*R* *H*
--
Life is too short to stuff a mushroom.
-- Storm Jameson
| |
| sk8r-365 2007-07-14, 1:15 am |
| Government satellites recorded Rockinghorse Winner saying:
>
> Can you install 32 bit Ubuntu on a 64 bit processor machine? I want all the
> compatibility of 32 bit apps, but most of the good deals on computers
> include AMD 64 bit chips.
>
Sure. I've installed Gentoo, Ubuntu and Debian on this 64bit box but
all of the distros listed were/are 32bit. I did use Gentoo 64 on
this machine yet there were too many things I missed - games, and
needed - OpenOffice and HP PSC1510 USB printer which wouldn't
function ... that was about two years ago, and things have improved I
understand.
--
sk8r-365
http://goodbye-microsoft.com/
| |
| Neil Ellwood 2007-07-14, 1:15 am |
| On 13 Jul 2007 20:26:19 GMT
Rockinghorse Winner <rockinghorse@deadtime.com> wrote:
> On 2007-07-12, jellybean stonerfish <stonerfish@geocities.com> wrote:
>
> Can you install 32 bit Ubuntu on a 64 bit processor machine? I want
> all the compatibility of 32 bit apps, but most of the good deals on
> computers include AMD 64 bit chips.
>
> *R* *H*
>
>
>
Yes
--
Neil
Reverse ie and delete l for email.
| |
| Burkhard Ott 2007-07-14, 7:13 am |
| Am Fri, 13 Jul 2007 17:56:36 +0000 schrieb Anton Ertl:
> Burkhard Ott <b.ott@derith.de> writes:
> But the maximum throughput does not change with whether you are using
> the processor for 32-bit or for 64-bit programs.
>
> - anton
I didn't told that, it depends on the bus clock and on the datatype itself
of course not if you are run a 64 bit or a 32 bit compiled application.
cheers
| |
| Burkhard Ott 2007-07-14, 7:13 am |
| Am Fri, 13 Jul 2007 12:37:46 -0600 schrieb sk8r-365:
> Government satellites recorded Burkhard Ott saying:
> Evidently. I *still* don't get it. I have a GIG of RAM on a 32bit OS with a
> 64bit machine (hardware) and there's less than 1/2 of that RAM currently
> in use. So I see no reason to think by adding another GIG I'll have more RAM
> in use. Rather, I should have a GIG and half unused then as opposed
> to having a half GIG unused now. What I'm taking away from this is
> you think - an analogy coming - that if I have a car which gets 30
> MPG and the car has 10 gallon gas tank, if I put on a 20 gallon gas
> tank, I should get better MPG.
Heheh, you removes from your V8 4 spark plugs because you can also drive
with 4.
I aggree that you don't need a x86_64 bit computer in a private
environment but if you have one you could also use the last 4 'spark
plugs'.
cheers
| |
| Björn Steinbrink 2007-07-14, 7:13 am |
| On Fri, 13 Jul 2007 09:38:36 +0000, Anton Ertl wrote:
> Burkhard Ott <b.ott@derith.de> writes:
>
> Unkless you are spending a lot of time in system calls, that does not
> matter. If it does, you can run a 64-bit kernel (which eliminates this
> problem) with a 32-bit userland.
That's not related to syscalls at all. To use more than 1GB of RAM (or
more exactly 896MB or so), you need to enable CONFIG_HIGHMEM_4G, which
splits the memory into a low mem and high mem part. Unfortunately, that
adds some overhead because it adds a level of indirection to the page
tables (and CONFIG_HIGHMEM_64G adds another one).
Björn
| |
| Björn Steinbrink 2007-07-14, 7:13 am |
| On Fri, 13 Jul 2007 12:37:46 -0600, sk8r-365 wrote:
> Government satellites recorded Burkhard Ott saying:
> Evidently. I *still* don't get it. I have a GIG of RAM on a 32bit OS
> with a 64bit machine (hardware) and there's less than 1/2 of that RAM
> currently in use. So I see no reason to think by adding another GIG I'll
> have more RAM in use. Rather, I should have a GIG and half unused then
> as opposed to having a half GIG unused now.
Is that actually unused memory, or is it used for buffers and caches? My
memory usage usually is around 100% (2GB), most of it being buffers and
caches. And I'm quite happy to have those 2GB, as they allow all the
stuff I work with to stay in memory, saving a good number of those damn
slow harddisk reads. :-)
Björn
| |
| Anton Ertl 2007-07-14, 7:13 am |
| =?iso-8859-1?b?Qmr2cm4=?= Steinbrink <B.Steinbrink@gmx.de> writes:
>On Fri, 13 Jul 2007 09:38:36 +0000, Anton Ertl wrote:
>
>
>That's not related to syscalls at all. To use more than 1GB of RAM (or
>more exactly 896MB or so), you need to enable CONFIG_HIGHMEM_4G, which
>splits the memory into a low mem and high mem part. Unfortunately, that
>adds some overhead because it adds a level of indirection to the page
>tables (and CONFIG_HIGHMEM_64G adds another one).
Not as far as I know. The normal 2-level page tables are good enough
for 4GB of address space, and that's all that's needed for
CONFIG_HIGHMEM_64G.
The difference with CONFIG_HIGHMEM_4G is that the kernel does not map
the 3GB of user address space and the physical memory into the kernel
address space at the same time, so it has to do extra work to access
both. But that affects only time spent in the kernel, i.e. system
time.
Actually, if you use a 64-bit kernel, the hardware uses a 4-level page
table, so if more levels did cost a lot, you would be faster with a
32-bit kernel. But fortunately, most page table accesses are cached
in the TLBs (and the levels don't play a role here at all), and for
those that miss the TLB, the top levels of the page tables are cached
in the L1 and L2 caches, so going through these levels is cheap.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
| |
| Björn Steinbrink 2007-07-14, 7:13 am |
| On Sat, 14 Jul 2007 10:31:05 +0000, Anton Ertl wrote:
> =?iso-8859-1?b?Qmr2cm4=?= Steinbrink <B.Steinbrink@gmx.de> writes:
Should've been "not only related to syscalls" (but still somewhat wrong,
see below).
[vbcol=seagreen]
>
> Not as far as I know. The normal 2-level page tables are good enough
> for 4GB of address space, and that's all that's needed for
> CONFIG_HIGHMEM_64G.
Sorry, I confused PAE to be 4-level and thus thought of 4G as being 3-
level.
> The difference with CONFIG_HIGHMEM_4G is that the kernel does not map
> the 3GB of user address space and the physical memory into the kernel
> address space at the same time, so it has to do extra work to access
> both. But that affects only time spent in the kernel, i.e. system time.
Yep. My mistake here was a) being a lot too terse and b) a brain-fart
when thinking about task switches (which I accounted for overhead not
caused due to syscalls).
AFAIK task switches (which are quite likely to happen a lot on desktop
boxes) also get more expensive with highmem enabled due to the required
remapping of memory. But of course a high rate of task switches depends
on tasks doing lots of blocking syscalls and therefore being rescheduled
quite often. So there's still a dependency on syscalls here.
> Actually, if you use a 64-bit kernel, the hardware uses a 4-level page
> table, so if more levels did cost a lot, you would be faster with a
> 32-bit kernel. But fortunately, most page table accesses are cached in
> the TLBs (and the levels don't play a role here at all), and for those
> that miss the TLB, the top levels of the page tables are cached in the
> L1 and L2 caches, so going through these levels is cheap.
Doesn't highmem also cause extra tlb flushes that are not present on
x86-64? And then (according to my broken "reverse" logic) higher level
page table would cause more overhead, which wouldn't be present on x86-64.
Anyway, touché ;-)
Björn, who shouldn't post that early and try to be smart at the same time
| |
| Anton Ertl 2007-07-14, 1:13 pm |
| =?iso-8859-1?b?Qmr2cm4=?= Steinbrink <B.Steinbrink@gmx.de> writes:
>On Sat, 14 Jul 2007 10:31:05 +0000, Anton Ertl wrote:
>AFAIK task switches (which are quite likely to happen a lot on desktop
>boxes) also get more expensive with highmem enabled due to the required
>remapping of memory. But of course a high rate of task switches depends
>on tasks doing lots of blocking syscalls and therefore being rescheduled
>quite often. So there's still a dependency on syscalls here.
Yes. Moreover, on a process switch the kernel has to change the page
tables anyway, so I don't think that this becomes more expensive with
CONFIG_HIGHMEM_4G.
>Doesn't highmem also cause extra tlb flushes that are not present on
>x86-64? And then (according to my broken "reverse" logic) higher level
>page table would cause more overhead, which wouldn't be present on x86-64.
AFAIK there are additional changes of the CR3 register (the root of
the page table tree) when the kernel is entered and left or when the
kernel tries to access physical memory, and changing that register
used to flush the TLB (I think modern CPUs avoid some of that
flushing), so yes, there might be more flushing, but again that's
associated with syscalls.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
| |
| Linonut 2007-07-14, 1:13 pm |
| After takin' a swig o' grog, sk8r-365 belched out this bit o' wisdom:
> Evidently. I *still* don't get it. I have a GIG of RAM on a 32bit OS with a
> 64bit machine (hardware) and there's less than 1/2 of that RAM currently
> in use. So I see no reason to think by adding another GIG I'll have more RAM
> in use. Rather, I should have a GIG and half unused then as opposed
> to having a half GIG unused now.
As you run ever more apps during a Linux session that may span /months/,
the kernel will keep caching stuff in RAM. Which is good, because RAM
is a lot faster than disk.
I've got 2 Gb, with only 36 Mb free, and 232 Mb of swap in use. And
that for only 150 tasks, of which only a couple dozen are applications
I'm running directly, and an uptime of only 25 days.
You want as much RAM as you can afford.
And when you add a Windows virtual machine into the equation, it is even
more useful.
--
Tux rox!
| |
| sk8r-365 2007-07-14, 1:13 pm |
| Government satellites recorded Björn Steinbrink saying:
>
> Is that actually unused memory, or is it used for buffers and caches? My
> memory usage usually is around 100% (2GB), most of it being buffers and
> caches. And I'm quite happy to have those 2GB, as they allow all the
> stuff I work with to stay in memory, saving a good number of those damn
> slow harddisk reads. :-)
>
Here's top at this momment - and I have several things going on:
Tasks: 107 total, 2 running, 105 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.7%us, 0.7%sy, 0.0%ni, 98.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1036472k total, 905620k used, 130852k free, 160592k buffers
Swap: 1534196k total, 0k used, 1534196k free, 503104k cached
--
sk8r-365
http://goodbye-microsoft.com/
| |
| Björn Steinbrink 2007-07-15, 7:13 am |
| On Sat, 14 Jul 2007 13:12:24 +0000, Anton Ertl wrote:
> =?iso-8859-1?b?Qmr2cm4=?= Steinbrink <B.Steinbrink@gmx.de> writes:
>
> Yes. Moreover, on a process switch the kernel has to change the page
> tables anyway, so I don't think that this becomes more expensive with
> CONFIG_HIGHMEM_4G.
But at least no kernel mappings are dropped from the TLB IIRC, as CR4.PGE
(Page global extensions) is set and the mappings in the kernel area are
marked as global. While that's still true for the lowmem area with
HIGHMEM4G enabled, it's not true for all the highmem mappings. Still
dependent on syscalls though.
>
> AFAIK there are additional changes of the CR3 register (the root of the
> page table tree) when the kernel is entered and left or when the kernel
> tries to access physical memory, and changing that register used to
> flush the TLB (I think modern CPUs avoid some of that flushing), so yes,
> there might be more flushing, but again that's associated with syscalls.
Flushes are (AFAIK) only avoided for the globally mapped lowmem area, see
above. Still syscalls, yep.
Björn
|
|
|
|
|