From: Luck, T. <ton...@in...> - 2003-02-11 21:42:56
|
> I've got a pseudo manpage for a new call I'm attempting=20 > to implement:=20 > shmbind(). The idea of the call is to allow userspace=20 > processes to bind=20 > shared memory segments to particular nodes' memory and do so=20 > according=20 > to certain policies. Processes would call shmget() as usual,=20 > but before=20 > calling shmat(), the process could call shmbind() to set up a binding=20 > for the segment. Then, any time pages from the shared segment are=20 > faulted into memory, it would be done according to this binding. > Any comments about the attatched manpage, the idea in=20 > general, how to improve it, etc. are definitely welcome. Why tie this to the sysV ipc shm mechanism? Couldn't you make a more general "mmbind()" call that applies to a "start, len" range of virtual addresses? This would work for your current usage (but you would apply it after the "shmat()"), but it would also be useful for memory allocated to a process with mmap(), sbrk() and even general .text/.data if you managed to call it before you touched pages. -Tony |
From: Matthew D. <col...@us...> - 2003-02-11 22:34:52
|
Luck, Tony wrote: >> I've got a pseudo manpage for a new call I'm attempting >>to implement: >>shmbind(). The idea of the call is to allow userspace >>processes to bind >>shared memory segments to particular nodes' memory and do so >>according >>to certain policies. Processes would call shmget() as usual, >>but before >>calling shmat(), the process could call shmbind() to set up a binding >>for the segment. Then, any time pages from the shared segment are >>faulted into memory, it would be done according to this binding. >> Any comments about the attatched manpage, the idea in >>general, how to improve it, etc. are definitely welcome. > > > Why tie this to the sysV ipc shm mechanism? Couldn't you make > a more general "mmbind()" call that applies to a "start, len" > range of virtual addresses? This would work for your current > usage (but you would apply it after the "shmat()"), but it would > also be useful for memory allocated to a process with mmap(), sbrk() > and even general .text/.data if you managed to call it before you > touched pages. > > -Tony I'd hoped to see how this proposal and pending patch went over with everyone, before attempting anything more broad. My last attempt at something similar to this failed due to being too invasive and complicated. My thoughts were to try something fairly straightforward and simple this time. The patch I'm working on to implement this could however lead to something like what you described if desired. I'm trying to allow for the possibility of expanding the power of bindings with my code. And I also think that these types of bindings could be useful in a more general way. Cheers! -Matt |
From: Christoph R. <cr...@sa...> - 2003-02-13 09:52:14
|
Hi Matt, On Tue, 11 Feb 2003, Matthew Dobson wrote: > I'd hoped to see how this proposal and pending patch went over with > everyone, before attempting anything more broad. My last attempt at > something similar to this failed due to being too invasive and > complicated. My thoughts were to try something fairly > straightforward and simple this time. But SYSV shm is a thin layer on top of tmpfs, which again is a thin layer on top of the page cache. So if you want to have something simple, you should work on the generic layer. For me a general mmbind() makes much more sense. Greetings Christoph |
From: Paul J. <pj...@sg...> - 2003-02-16 04:05:29
|
On Tue, 11 Feb 2003, Luck, Tony wrote: > Why tie this to the sysV ipc shm mechanism? Couldn't you make > a more general "mmbind()" call that applies to a "start, len" > range of virtual addresses? I'll second that motion. Presumably this could work on any range of pages, using the kernel routines to split vmareas as need be. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj...@sg...> 1.650.933.1373 |
From: Christoph H. <hc...@in...> - 2003-02-16 09:52:10
|
On Tue, Feb 11, 2003 at 01:51:23PM -0800, Paul Jackson wrote: > I'll second that motion. Presumably this could work > on any range of pages, using the kernel routines to > split vmareas as need be. yes - it would be the same type of attribute setting we currently do in mprotect, madvise, etc.. Which reminds me that I need to fix up my split_vma() changes to do proper merging, maybe reusing bits from akpm's new vma merging code. |