lkml.org 
[lkml]   [2004]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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:
    >
    > ftp://ftp.kernel.org/pub/linux/kernel/people/mbligh/patches/2.6.3/2.6.3-mjb1/410-topdown

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

    thanks.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:01    [W:0.033 / U:30.592 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site