RE: [Lse-tech] [rfc][api] Shared Memory Binding

RE: [Lse-tech] [rfc][api] Shared Memory Binding

[Luck, Tony]

> 	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
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

RE: [Lse-tech] [rfc][api] Shared Memory Binding

[Paul Jackson]

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@sgi.com> 1.650.933.1373

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: [Lse-tech] [rfc][api] Shared Memory Binding

[Matthew Dobson]

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: [Lse-tech] [rfc][api] Shared Memory Binding

[Christoph Rohland]

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


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: [Lse-tech] [rfc][api] Shared Memory Binding

[Christoph Hellwig]

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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>