[lkml]   [2002]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] recognize MAP_LOCKED in mmap() call wrote:
    > Andrew Morton wrote:
    > >(SuS really only anticipates that mmap needs to look at prior mlocks
    > >in force against the address range. It also says
    > >
    > > Process memory locking does apply to shared memory regions,
    > >
    > >and we don't do that either. I think we should; can't see why SuS
    > >requires this.)
    > Let me make sure I read what you said correctly. Does this mean that Linux
    > 2.4 (or 2.5) kernels do not lock shared memory regions if a process uses
    > mlockall?

    Linux does lock these regions. SuS seems to imply that we shouldn't.
    But we should.

    > If not, that is *really bad* for our real time applications. We don't want
    > to take a page fault while running some 80hz task, just because some
    > non-real time application tried to use what little physical memory we allow
    > for the kernel and all other applications.
    > I asked a related question about a week ago on linux-mm and didn't get a
    > response. Basically, I was concerned that top did not show RSS == Size when
    > mlockall(MCL_CURRENT|MCL_FUTURE) was called. Could this explain the
    > difference or is there something else that I'm missing here?

    That mlockall should have faulted everything in. It could be an
    accounting bug, or it could be a bug. That's not an aspect which
    gets tested a lot. I'll take a look.
    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.022 / U:5.824 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site