LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Hugh Dickins <email@example.com> To: David Howells <firstname.lastname@example.org> Cc: email@example.com, Robin Holt <firstname.lastname@example.org>, "Kawai, Hidehiro" <email@example.com>, Andrew Morton <firstname.lastname@example.org>, kernel list <email@example.com>, Pavel Machek <firstname.lastname@example.org>, Alan Cox <email@example.com>, Masami Hiramatsu <firstname.lastname@example.org>, sugita <email@example.com>, Satoshi OSHIMA <firstname.lastname@example.org>, email@example.com, Robin Getz <firstname.lastname@example.org> Subject: Re: Move to unshared VMAs in NOMMU mode? Date: Thu, 15 Mar 2007 21:20:12 +0000 (GMT) [thread overview] Message-ID: <Pine.LNX.email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> 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 the FRV context for example: >... > Another way of dealing with the nattch count on NOMMU systems is to do it > through the VML list, but that then needs more special casing in the SHM > driver and perhaps others. > > Thoughts? Thoughts are in regrettably short supply at my end. I do appreciate all the trouble you've taken to explain it, in terms I'd understand. And the way you've taken on board my anxiety about vma assumptions diverging between NO/MMU. 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. Actually, I'm rather surprised SHM needs any such nattch count, I'd expect it to deducible from file->f_count and mode&SHM_DEST (but haven't investigated whether that really works out at all). If you just need a little CONFIG_MMU in ipc/shm.c to solve your problem, I don't think more is justified. Your struct vm_region idea does look more to my taste than what you presently have; yet if you pursue it, I think it would just make divergence worse wouldn't it? NOMMU wanting vma to contain a pointer to vm_region, MMU wanting vm_region embedded in vma. I don't really understand why NOMMU chooses to share vmas, or vm_regions, rather than just sharing the data which they indicate. Just because you can use less memory that way? But no need to justify it now, I'm unlikely to study it in detail. Hugh
next prev parent reply other threads:[~2007-03-15 21:20 UTC|newest] Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-02-16 13:34 [PATCH 0/4] coredump: core dump masking support v3 Kawai, Hidehiro 2007-02-16 13:39 ` [PATCH 1/4] coredump: add an interface to control the core dump routine Kawai, Hidehiro 2007-02-16 13:40 ` [PATCH 2/4] coredump: ELF: enable to omit anonymous shared memory Kawai, Hidehiro 2007-02-16 13:41 ` [PATCH 3/4] coredump: ELF-FDPIC: " Kawai, Hidehiro 2007-02-16 13:42 ` [PATCH 4/4] coredump: documentation for proc entry Kawai, Hidehiro 2007-02-16 15:05 ` [PATCH 3/4] coredump: ELF-FDPIC: enable to omit anonymous shared memory David Howells 2007-02-16 16:50 ` Robin Holt 2007-02-16 20:09 ` David Howells 2007-03-02 16:55 ` Hugh Dickins 2007-03-03 14:10 ` David Howells 2007-03-05 19:04 ` Hugh Dickins 2007-03-06 18:13 ` David Howells 2007-03-09 14:12 ` Move to unshared VMAs in NOMMU mode? David Howells 2007-03-12 20:50 ` Robin Getz 2007-03-13 10:14 ` David Howells 2007-03-15 21:20 ` Hugh Dickins [this message] 2007-03-15 22:47 ` David Howells 2007-03-19 19:23 ` Eric W. Biederman 2007-03-20 11:06 ` David Howells 2007-03-20 16:48 ` Eric W. Biederman 2007-03-20 19:12 ` David Howells 2007-03-20 19:51 ` David Howells 2007-03-21 16:11 ` David Howells 2007-03-03 14:25 ` [PATCH] NOMMU: Hide vm_mm in NOMMU mode David Howells 2007-02-20 9:45 ` [PATCH 3/4] coredump: ELF-FDPIC: enable to omit anonymous shared memory Kawai, Hidehiro 2007-02-20 10:58 ` David Howells 2007-02-20 12:56 ` Robin Holt 2007-02-21 10:00 ` Kawai, Hidehiro 2007-02-21 11:33 ` David Howells 2007-02-21 11:54 ` Robin Holt 2007-02-22 5:33 ` Kawai, Hidehiro 2007-02-22 11:47 ` David Howells 2007-02-16 15:08 ` [PATCH 0/4] coredump: core dump masking support v3 David Howells 2007-02-20 9:48 ` Kawai, Hidehiro 2007-02-24 3:32 ` Markus Gutschke 2007-02-24 11:39 ` Pavel Machek 2007-03-01 12:35 ` Kawai, Hidehiro 2007-03-01 18:16 ` Markus Gutschke 2007-02-24 10:02 ` David Howells 2007-02-24 20:01 ` Markus Gutschke 2007-02-26 11:49 ` David Howells 2007-02-26 12:01 ` Pavel Machek 2007-02-26 12:42 ` David Howells
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Pine.LNX.email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).