All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [parisc-linux] Swap space limitions for Linux on parisc
@ 2002-03-09  2:38 Duraid Madina
  2002-03-09  2:45 ` Randolph Chung
  0 siblings, 1 reply; 7+ messages in thread
From: Duraid Madina @ 2002-03-09  2:38 UTC (permalink / raw)
  To: parisc-linux

John wrote:

>P.S. Note that we don't support 64 bit user space processes yet, so you
>would probably find it difficult to consume extreme amounts of swap
>space, since each process can only address ~4Gb of memory.	

(!!!)

*ponders tearing up his code into multiple processes*

The 'yet' above gives me hope; will 64 bit user space processes be
supported anytime soon? Being able to malloc(1<<36) would be nice!

	Duraid

^ permalink raw reply	[flat|nested] 7+ messages in thread
* RE: [parisc-linux] Swap space limitions for Linux on parisc
@ 2002-03-09  5:34 John Marvin
  0 siblings, 0 replies; 7+ messages in thread
From: John Marvin @ 2002-03-09  5:34 UTC (permalink / raw)
  To: parisc-linux

>
> > > The 'yet' above gives me hope; will 64 bit user space processes be
> > > supported anytime soon? Being able to malloc(1<<36) would be nice!
> >
> > I sure hope not.... there is a lot of work involved to bring
> > up toolchains and all the applications to support two
> > different userlands. We still have a lot of work to do just
> > to stablize 32-bit userspace. Check the list archives, this
> > has been discussed before, and once fairly recently.
>
> I had a bit of a peek around the archives, wow, I guess hppa64 isn't the
> most 'comfortable' place for a g++ developer just now.

Well, basic gcc, binutils already work because we need that to build a
64 bit kernel. g++ is another story (which I don't know anything about).
The biggest missing piece is support for 64 bit shared libraries. I'm
not even sure there is a complete design for how that is going to work.

Then of course, a 64 bit version of glibc has to be built. Since glibc
has already been ported to other 64 bit architectures, and since it has
been ported to 32 bit parisc linux, there may not be that much work here,
but the code size is so huge, it probably is not trivial.

Finally, there is some more kernel work to be done, primarily in VM
support and syscalls.  I plan to do this work some day, but haven't been
highly motivated since there hasn't been much demand yet.

> > This is not to say it couldn't be done of course. This is
> > GNU/Linux, you have all the source, go nuts.. :-)
>
> Project deadline soon :( must.. find.. cheap.. 64 bit machine
>
> > But now you have me curious, what app are you writing that
> > needs >4G of address space?
>
> A computational physics code. Ideally I would run it in 100s of GB of
> RAM. About two months of pain went into making it work (reasonably
> efficiently, in theory at least) in 100s of GB of swap.
>
> Now you have *me* curious; I don't mean to be an ignorant asshole, but
> what's the point of hppa64 if you *don't* support >4G address space?
>
> *crying* does HP-UX support >4G address space? *finds wallet* :(
> Hmm, probably have to shell out more $$$ for the HP compilers too :\
>
>         Duraid

Yes, HP-UX does support >4Gb address space. And yes, you will probably
have to pay extra for the compilers. Another problem is that HP-UX
might not install without supported CD-ROM, disks, etc. From the
ordering page it wasn't clear if you could order HP-UX media without
getting a CD-ROM (which we charge $520 for. Such a bargain!).

So, another option might be a statically linked 64 bit gcc "compute
engine" app that used only a minimum of direct syscalls (no glibc) to
communicate with a 32 bit front end app.  If the compute part of your code
is heavily g++ dependent, this might not be feasible.  This would still
require the kernel work mentioned above to be done.

John Marvin
jsm@fc.hp.com

^ permalink raw reply	[flat|nested] 7+ messages in thread
* [parisc-linux] Swap space limitions for Linux on parisc
@ 2002-03-09  1:27 John Marvin
  0 siblings, 0 replies; 7+ messages in thread
From: John Marvin @ 2002-03-09  1:27 UTC (permalink / raw)
  To: parisc-linux

> Forget about swapping over NFS.  It's prone to deadlock under
> stress.  I think we support 2GB/file and up to 8 files, but I may be
> underestimating... John would know.

For a 32 bit kernel:
    128 Gb per file, up to 32 files for a total of 4 Tb.

However, there are two limitations that you have to work around to get that:

    1) mkswap was never modified for parisc, so I believe it sets a limit
    of 2 Gb.  I once hacked a version of it, but I never got around to
    submitting the change, because I had some questions about some
    comments in the code that I believed were out of date, but wasn't sure,
    put it on the backburner, and dropped the ball.

    Anyway, I believe the change was simple, and I tested at least a 16 Gb
    swap partition at one time.

    2) Although we can support 32 swap files, Linux currently has a limit
    of 8. However, I think the only change to allow 32 is to change
    MAX_SWAPFILES in include/linux/swap.h to 32. I don't think there are
    any other intrinsic limitations there.

    3) Note that a swap map is allocated for each swap file.  The swap map
    takes 2 bytes for each page of swap.  This swap map is vmalloc'd, so
    that places another limitation on the total swap size.  The vmalloc
    address space starts after the end of physical memory, so the more
    physical memory you add, the LESS swap space you can have.  But that
    isn't likely to become an issue until you need more than a terabyte of
    swap space.

For a 64 bit kernel the size of a swap partition can be even larger than
128 Gb.  But I really can't say how much larger, because there are a bunch
of variables that get involved and I don't have the time to try to muddle
through them all. Some of those variables:

    1) Disk size limits / Disk addressing limits
    2) swap partition format limits
    3) physical memory limits (limits size of all swap maps)
    4) vmalloc address space limits (limits size of all swap maps)

Note that I didn't mention the SWP_OFFSET limit, which is the main limitation
for the 32 bit kernel. For a 32 bit kernel we dedicate 25 bits to swap
offset, which gives us the 128 Gb limit (2^25 x 4K page size). For a 64
bit kernel we have 57 bits, so that is not the limiting factor. One of
the above will set the limit.

John

P.S. Note that we don't support 64 bit user space processes yet, so you
would probably find it difficult to consume extreme amounts of swap
space, since each process can only address ~4Gb of memory.

^ permalink raw reply	[flat|nested] 7+ messages in thread
end of thread, other threads:[~2002-03-09  5:37 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-03-09  2:38 [parisc-linux] Swap space limitions for Linux on parisc Duraid Madina
2002-03-09  2:45 ` Randolph Chung
2002-03-09  3:00   ` Duraid Madina
2002-03-09  3:05     ` Matthew Wilcox
2002-03-09  3:23       ` Duraid Madina
  -- strict thread matches above, loose matches on Subject: below --
2002-03-09  5:34 John Marvin
2002-03-09  1:27 John Marvin

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.