David Howells <[EMAIL PROTECTED]> wrote:
> I don't quite what your limitations are
(8) Handling mappings that extend beyond the end of file.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
David Howells [EMAIL PROTECTED] wrote:
I don't quite what your limitations are
(8) Handling mappings that extend beyond the end of file.
David
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
David Howells <[EMAIL PROTECTED]> wrote:
> I don't quite what your limitations are
(7) Two shared mappings on the same offset in the same file must, of
necessity, appear at the same address. This means you get two VMAs in the
rbtree at the same place.
David
-
To unsubscribe from
Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> >> For shared mappings you share in some sense the page cache.
> >
> > Currently, no - not unless the driver does something clever as ramfs does.
> > Sharing through the page cache is a nice idea, but it has some limitations,
> > mainly that
David Howells <[EMAIL PROTECTED]> writes:
> Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
>> As I understand your description for non-shared mappings the VMAs are
>> per process.
>
> Are you talking about the current state of play? If so, not precisely. In
> the current scheme of things, *all*
Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> As I understand your description for non-shared mappings the VMAs are
> per process.
Are you talking about the current state of play? If so, not precisely. In
the current scheme of things, *all* VMAs are kept in a global tree and are
globally
Eric W. Biederman [EMAIL PROTECTED] wrote:
As I understand your description for non-shared mappings the VMAs are
per process.
Are you talking about the current state of play? If so, not precisely. In
the current scheme of things, *all* VMAs are kept in a global tree and are
globally
David Howells [EMAIL PROTECTED] writes:
Eric W. Biederman [EMAIL PROTECTED] wrote:
As I understand your description for non-shared mappings the VMAs are
per process.
Are you talking about the current state of play? If so, not precisely. In
the current scheme of things, *all* VMAs are
Eric W. Biederman [EMAIL PROTECTED] wrote:
For shared mappings you share in some sense the page cache.
Currently, no - not unless the driver does something clever as ramfs does.
Sharing through the page cache is a nice idea, but it has some limitations,
mainly that non-sharing then
David Howells [EMAIL PROTECTED] wrote:
I don't quite what your limitations are
(7) Two shared mappings on the same offset in the same file must, of
necessity, appear at the same address. This means you get two VMAs in the
rbtree at the same place.
David
-
To unsubscribe from this
I'm just trying to digest this a little.
As I understand your description for non-shared mappings the VMAs are
per process.
For shared mappings you share in some sense the page cache.
My gut feel says just keep a vma per process of the regions the
process has and do the appropriate book
I'm just trying to digest this a little.
As I understand your description for non-shared mappings the VMAs are
per process.
For shared mappings you share in some sense the page cache.
My gut feel says just keep a vma per process of the regions the
process has and do the appropriate book
Hugh Dickins <[EMAIL PROTECTED]> wrote:
> But if "the SYSV SHM problem" you mention at the beginning
> is just the "nattch" problem you mention at the end, I doubt
> that's worth such a redesign as you're considering here.
Yes, as far as I know that's the problem. nattch is available to
On Fri, 9 Mar 2007, David Howells wrote:
>
> I've been considering how to deal with the SYSV SHM problem, and I think we
> may have to move to unshared VMAs in NOMMU mode to deal with this. Currently,
> what we have is each mm_struct has in its arch-specific context argument a
&g
On Fri, 9 Mar 2007, David Howells wrote:
I've been considering how to deal with the SYSV SHM problem, and I think we
may have to move to unshared VMAs in NOMMU mode to deal with this. Currently,
what we have is each mm_struct has in its arch-specific context argument a
list of VMLs. Take
Hugh Dickins [EMAIL PROTECTED] wrote:
But if the SYSV SHM problem you mention at the beginning
is just the nattch problem you mention at the end, I doubt
that's worth such a redesign as you're considering here.
Yes, as far as I know that's the problem. nattch is available to userspace and
Robin Getz <[EMAIL PROTECTED]> wrote:
> We (noMMU) folks need to have special code anyway - so why not put it there,
> and try not to increase memory footprint?
I'd like to have the drivers and filesystems need to know as little as possible
about whether they're working in MMU-mode or
Robin Getz [EMAIL PROTECTED] wrote:
We (noMMU) folks need to have special code anyway - so why not put it there,
and try not to increase memory footprint?
I'd like to have the drivers and filesystems need to know as little as possible
about whether they're working in MMU-mode or NOMMU-mode -
On Fri 9 Mar 2007 09:12, David Howells pondered:
> I've been considering how to deal with the SYSV SHM problem, and I think we
> may have to move to unshared VMAs in NOMMU mode to deal with this.
Thanks for putting some good thoughts down.
> Currently, what we have is each mm_struct h
On Fri 9 Mar 2007 09:12, David Howells pondered:
I've been considering how to deal with the SYSV SHM problem, and I think we
may have to move to unshared VMAs in NOMMU mode to deal with this.
Thanks for putting some good thoughts down.
Currently, what we have is each mm_struct has in its
I've been considering how to deal with the SYSV SHM problem, and I think we
may have to move to unshared VMAs in NOMMU mode to deal with this. Currently,
what we have is each mm_struct has in its arch-specific context argument a
list of VMLs. Take the FRV context for example:
[include
I've been considering how to deal with the SYSV SHM problem, and I think we
may have to move to unshared VMAs in NOMMU mode to deal with this. Currently,
what we have is each mm_struct has in its arch-specific context argument a
list of VMLs. Take the FRV context for example:
[include
22 matches
Mail list logo
