[lkml]   [2004]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.4.23aa2 (bugfixes and important VM improvements for the high end)
On Fri, Feb 27, 2004 at 11:00:44PM -0800, Martin J. Bligh wrote:
> > The last issue that we may run into are apps assuming the stack is at 3G
> > fixed, some jvm assumed that, but they should be fixed by now (at the
> > very least it's not hard at all to fix those).
> All the potential solutions we're discussing hit that problem so I don't
> see it matters much which one we choose ;-)

I agree, I thought about it too, but I didn't mention that since
theoretically 4:4 has a chance to start with a stack at 3G and to depend
on the userspace startup to relocate it at 4G ;). x86-64 does something
like that to guarantee 100% compatibility.

> > It also depends on the performance difference if this is worthwhile, if
> > the difference isn't very significant 4:4 will be certainly prefereable
> > so you can also allocate 4G in the same task for apps not using syscalls
> > or page faults or flood of network irqs.
> There are some things that may well help here: one is vsyscall gettimeofday,
> which will fix up the worst of the issues (the 30% figure you mentioned
> to me in Ottowa), the other is NAPI, which would help with the network
> stuff.

I think it's very fair to benchmark vsyscalls with 2.5:1.5 vs vsyscalls
with 4:4.

However remeber you said you want a generic kernel for 64G right? Not
all userspaces will use vsyscalls, and it's not just one app using
gettimeofday. As of today no production userspace uses vgettimeofday in
x86 yet. I mean, we can tell people to always use vsyscalls with the 4:4
kernel and it's acceptable, but it's not as generic as 2.5:1.5.

> Bill had a patch to allocate mmaps, etc down from the top of memory and
> thus elimininate TASK_UNMAPPED_BASE, and shift the stack back into the
> empty hole from 0-128MB of memory where it belongs (according to the spec).
> Getting rid of those two problems gives us back a little more userspace
> as well.
> Unfortunately it does seem to break some userspace apps making stupid
> assumptions, but if we have a neat way to mark the binaries (Andi was
> talking about personalities or something), we could at least get the
> big mem hogs to do that (databases, java, etc).

I read something about this issue. I agree it must be definitely marked.
apps may very well make assumptions about that space being empty below
128m and overwrite it with a mmap() (mmap will just silent overwrite),
and I'm unsure if we can claim that to be an userspace bug..., I guess
most people will blame the kernel ;)

Now that x86 is dying it probably don't worth to mark the binaries, the
few apps needing this should relocate the stack by hand and setup the
growsdown bitflag. plus they should lower mapped base by hand with the
/proc tweak like we do in 2.4.

I agree having the stack growsdown at 128 is the best for the db setup,
but I doubt we can make it generic and automatic for all apps. Also it's
not the stack really the problem in terms of genericity, infact with
recursive algos the stack may need to grow a lot, and having it at 128m
could segfault. As for mapped-base the space between 128 and 1G may as
well be assumpd empty by the apps, so relocation is possible on demand
by the app. I doubt we can do better than the above without taking risks ;)

> I have a copy of Bill's patch in my tree if you want to take a look:

thanks for the pointer.

> That might make your 2.5/1.5 proposal more feasible with less loss of
> userspace.

Yes. I was sort of assuming that we would use the mapped-base tweak for
achieving that, the relocation of the stack is a good idea, and it's
doable all in userspace (though it's not generic/automatic).

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:01    [W:0.065 / U:45.428 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site