On Sat, Mar 16, 2002 at 01:27:52PM -0700, Richard Gooch wrote:
> [email protected] writes:
> > On Sat, Mar 16, 2002 at 09:05:04PM +0100, Andi Kleen wrote:
> > > That will hopefully change eventually because 2M pages are a bit help for
> > > a lot of applications that are limited by TLB thrashing, but needs some
> > > thinking on how to avoid the fragmentation trap (e.g. I'm considering
> > > to add a highmem zone again just for that and use rmap with targetted
> > > physical freeing to allocating them)
> >
> > To me, once you have a G of memory, wasting a few meg on unused
> > process memory seems no big deal.
>
> I'm not happy to throw away 2 MiB per process. My workstation has 1
> GiB of RAM, and 65 processes (and that's fairly low compared to your
> average desktop these days, because I just use olwm and don't have a
> fancy desktop or lots of windows). You want me to throw over 1/8th of
> my RAM away?!?
Why not? If you just ran vim on console you'd be more productive and
not need all those worthless processes.
At 4KB/page and 8bytes/pte a
1G process will need at least 2MB of pte alone ! Add in the 4 layers,
the software VM struct, ...
>
> And in fact, isn't it going to be more than 2 MiB wasted per process?
> For each shared object loaded, only partial pages are going to be
> used. *My* libc is less than 700 KiB, so I'd be wasting most of a page
> to map it in.
You're using a politically incorrect libc.
But sure, big pages are not always good.
> I want that 1 GiB of RAM to be used to cache most of my data. Those
> NASA 1km/pixel satellite mosaics of the world are pretty big, you know
> (21600x21600x3 per hemisphere:-).
>
> Regards,
>
> Richard....
> Permanent: [email protected]
> Current: [email protected]
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
http://www.fsmlabs.com http://www.rtlinux.com
[email protected] writes:
> On Sat, Mar 16, 2002 at 01:27:52PM -0700, Richard Gooch wrote:
> > [email protected] writes:
> > > On Sat, Mar 16, 2002 at 09:05:04PM +0100, Andi Kleen wrote:
> > > > That will hopefully change eventually because 2M pages are a bit help for
> > > > a lot of applications that are limited by TLB thrashing, but needs some
> > > > thinking on how to avoid the fragmentation trap (e.g. I'm considering
> > > > to add a highmem zone again just for that and use rmap with targetted
> > > > physical freeing to allocating them)
> > >
> > > To me, once you have a G of memory, wasting a few meg on unused
> > > process memory seems no big deal.
> >
> > I'm not happy to throw away 2 MiB per process. My workstation has 1
> > GiB of RAM, and 65 processes (and that's fairly low compared to your
> > average desktop these days, because I just use olwm and don't have a
> > fancy desktop or lots of windows). You want me to throw over 1/8th of
> > my RAM away?!?
>
> Why not? If you just ran vim on console you'd be more productive and
> not need all those worthless processes.
Yeah, right.
> At 4KB/page and 8bytes/pte a
> 1G process will need at least 2MB of pte alone ! Add in the 4 layers,
> the software VM struct, ...
This isn't a dedicated bigass-image display box. It's a workstation.
It's where I read email, hack kernels, write visualisation tools and
stuff like that.
And I can afford a few MiB of RAM for PTE's and such for *the one
process which is mapping my huge data files*! That's effectively a
small, one-time cost. Every other process doesn't have a significant
PTE cost.
I'm not using my kernel as a device driver for an image display
programme. I'm using it run a box that's generally useful to me.
> > And in fact, isn't it going to be more than 2 MiB wasted per process?
> > For each shared object loaded, only partial pages are going to be
> > used. *My* libc is less than 700 KiB, so I'd be wasting most of a page
> > to map it in.
>
> You're using a politically incorrect libc.
Yeah :-) Man it feels good.
> But sure, big pages are not always good.
Hm. With wide TLB's, what are the benefits to big pages? One
pathological case that hit me a few years back was a workload which
bounced around in VM in a pattern that really thrash the cache due to
aliasing. It wouldn't have been a problem if we had truly fully
set-associative caches, rather than N-way (where N is 2, 4 or 8
usually). But big pages won't help that much here (it's just a way of
reducing TLB thrash, but doesn't help with cache thrashing).
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
On Sat, 16 Mar 2002, Richard Gooch wrote:
> And I can afford a few MiB of RAM for PTE's and such for *the one
> process which is mapping my huge data files*!
Once you have this, you might as well make that granularity
per VMA.
This gives you the advantage of being able to share the
mapping for libc.so ;)
>From what I can see, you'll basically want large pages
for:
1) Oracle and maybe other large shared memory situations
where the page table overhead would otherwise be
prohibitively high
2) scientific calculations and other programs with a huge
dataset where TLB misses would be prohibitively slow
regards,
Rik
--
<insert bitkeeper endorsement here>
http://www.surriel.com/ http://distro.conectiva.com/