First jump into the AMD 64-bit world... - Debian

This is a discussion on First jump into the AMD 64-bit world... - Debian ; On 2007-07-12, jellybean stonerfish 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 ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 33 of 33

Thread: First jump into the AMD 64-bit world...

  1. Re: First jump into the AMD 64-bit world...

    On 2007-07-12, jellybean stonerfish 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

  2. Re: First jump into the AMD 64-bit world...

    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/

  3. Re: First jump into the AMD 64-bit world...

    On 13 Jul 2007 20:26:19 GMT
    Rockinghorse Winner wrote:

    > On 2007-07-12, jellybean stonerfish 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*
    >
    >
    >

    Yes


    --
    Neil
    Reverse ie and delete l for email.

  4. Re: First jump into the AMD 64-bit world...

    Am Fri, 13 Jul 2007 17:56:36 +0000 schrieb Anton Ertl:

    > Burkhard Ott writes:
    >>Am Fri, 13 Jul 2007 09:38:36 +0000 schrieb Anton Ertl:

    > 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

  5. Re: First jump into the AMD 64-bit world...

    Am Fri, 13 Jul 2007 12:37:46 -0600 schrieb sk8r-365:

    > Government satellites recorded Burkhard Ott saying:
    >> Am Thu, 12 Jul 2007 21:11:57 -0600 schrieb sk8r-365:
    >>

    > 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

  6. Re: First jump into the AMD 64-bit world...

    On Fri, 13 Jul 2007 09:38:36 +0000, Anton Ertl wrote:

    > Burkhard Ott writes:
    >> 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.


    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

  7. Re: First jump into the AMD 64-bit world...

    On Fri, 13 Jul 2007 12:37:46 -0600, sk8r-365 wrote:

    > Government satellites recorded Burkhard Ott saying:
    >> Am Thu, 12 Jul 2007 21:11:57 -0600 schrieb sk8r-365:
    >>
    >>> 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?
    >>>
    >>>

    >> 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.


    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

  8. Re: First jump into the AMD 64-bit world...

    =?iso-8859-1?b?Qmr2cm4=?= Steinbrink writes:
    >On Fri, 13 Jul 2007 09:38:36 +0000, Anton Ertl wrote:
    >
    >> Burkhard Ott writes:
    >>> 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.

    >
    >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

  9. Re: First jump into the AMD 64-bit world...

    On Sat, 14 Jul 2007 10:31:05 +0000, Anton Ertl wrote:

    > =?iso-8859-1?b?Qmr2cm4=?= Steinbrink writes:
    >>On Fri, 13 Jul 2007 09:38:36 +0000, Anton Ertl wrote:
    >>
    >>> Burkhard Ott writes:
    >>>> 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.

    >>
    >>That's not related to syscalls at all. To use more than 1GB of RAM (or


    Should've been "not only related to syscalls" (but still somewhat wrong,
    see below).

    >>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.


    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

  10. Re: First jump into the AMD 64-bit world...

    =?iso-8859-1?b?Qmr2cm4=?= Steinbrink 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

  11. Re: First jump into the AMD 64-bit world...

    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!

  12. Re: First jump into the AMD 64-bit world...

    Government satellites recorded Bjrn 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/

  13. Re: First jump into the AMD 64-bit world...

    On Sat, 14 Jul 2007 13:12:24 +0000, Anton Ertl wrote:

    > =?iso-8859-1?b?Qmr2cm4=?= Steinbrink 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.


    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.

    >>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.


    Flushes are (AFAIK) only avoided for the globally mapped lowmem area, see
    above. Still syscalls, yep.

    Björn

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2