[lkml]   [2002]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] Arch option to touch newly allocated pages
    On March 7, 2002 05:50 pm, wrote:
    > On Thu, Mar 07, 2002 at 04:31:10PM +0100, Daniel Phillips wrote:
    > > > > > Why is that a fix? And how can it work?
    > > > >
    > > > > Since there is always at least one freeable page in the system (or we're oom) then
    > > > > we just have to find it and we know we can forcibly unmap it. We do need to know
    > > > > the total of pinned pages, I should have said locked/dirty/pinned.
    > > >
    > > > What if we are oom?
    > >
    > > This problem didn't get any worse, we still have to deal with it. We can wait, so
    > > we deal with it in the standard way (i.e., we puke, have to do something about that.)
    > So it can return NULL?

    Returning null here won't help if the caller doesn't have a fallback, or if the fallback
    is unacceptable, such as losing a filesystem transaction.

    > > > What if we are on our way to deadlock?
    > >
    > > huh??
    > Process A needs 4 pages, Process B needs 4 pages, each grabs 3.

    This is no new deadlock. Supposing each has successfully grabbed 3, what
    good does it do if the process is too clueless to release the pages it's
    already grabbed, because the 4th page alloc fails? (The first 3 may have
    been alloced in a completely different part of the program.) And if the
    process does know how to do this, it should tell the VM that *then* the VM
    should feel free to fail it.

    > One easy, traditional unix algorithm for dealing with this is
    > for(i=0; i < 4; i++)if !(p[i]=kmallloc(...))
    > free all that we have so far

    Just or in GFP_ok_to_fail there.

    > > > What if the caller of kmalloc will make less good use of the page
    > > > than the current owner of the page?
    > >
    > > That's life, that's what lrus are for.
    > Really? I thought LRUs were to approximate working sets. Obviously
    > if a program is kmallocing its working set is changing but that
    > does not tell us anything about whether it is a correct decision to
    > rip a page from the working set of another process.

    We're getting way far from the original question here. Our lru has no
    concept of working set, it's completely global. That's not so great and
    it's another problem to tackle. Sometime.

    > > You won't find one if you don't look for it.
    > I'm too dumb to come up with a solution here, but you are the one
    > changing the interface, so surely you have a couple of "less borked"
    > solutions in mind - right?

    Yes. Well, I'm not alone here, ping Marcelo on that if you like. This is
    known borkness that's been deferred while more pressing borkness is dealt

    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 13:24    [W:0.023 / U:64.380 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site