Re: Mapping a piece of one process' addrspace to another?
Alexander Viro writes: >Erm. If ioctls are device-specific - the program is already bound to >specific driver. If they are for class of devices (and if I guessed >right that's the case you are interested in - sound, isn't it?) we >could let the stub driver in kernel open two pipes and redirect >read()/write() on device to the first one turn ioctls into read()/write() >on the second. That way you can get userland programs serving that >stuff with no magic required. One problem, in addition to the points Abramo made, is that there's no metadata that goes along with the data you're writing to the pipe. This is fine as long as there's only one process reading, but in the case of a single driver serving multiple instances of an open file, there has to be some way for the userspace driver to communicate to the kernel which open file needs to get the data. A similar problem is that metadata needs to accompany the read request when the userspace driver gets it (i.e., current file position, file flags, size of the read that was requested, etc.) Although, that data might be transmitted on the OOB channel. Also, even though my framework right now only does character devices, it's a pretty simple extension to support userspace block devices and network devices as well. In these cases I think using a pipe gets more and more complicated. >From reading all the responses to the thread (thanks, everyone, for your useful comments), it sounds like the best thing to do is use Manfred's zerocopy pipe code as a model and implement something similar in my framework. It's not really that much code anyway so it's not much of a waste reimplementing it. And, I think reimplementing those 30 lines will be much simpler than trying to manage 2 parallel channels. If the zerocopy patch becomes part of the kernel anyway, it gets even simpler, since I can probably just call pio_copy_to_user instead of copying it. Regards, Jer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Mapping a piece of one process' addrspace to another?
Alexander Viro writes: >On Wed, 7 Mar 2001, Jeremy Elson wrote: > >> Right now, my code looks something like this: (it might make more >> sense if you know that I've written a framework for writing user-space >> device drivers... I'm going to be releasing it soon, hopefully after I >> resolve this performance problem. Or maybe before, if it's hard.) > >Ugh. Why not make that a named pipe and use zerocopy stuff for pipes? >I.e. why bother with making it look like a character device rather than >a FIFO? Well, because it's a character device :-). i.e,. the framework allows you to write a userspace program that services callbacks for character devices. Inside the kernel, all open()/release()/ioctl()/etc calls for the device are proxied out to userspace where a library calls a userspace callback, and the result goes back to the kernel where it is then returned to the calling process. The problem is just that to return data (instead of just a retval), as is needed for read and some ioctls, it leads to 3 copies as I described earlier. BTW, where are the zerocopy patches for pipes? Maybe I'm missing something but it seems that pipes inside the kernel are still implememented by copying into the kernel and then copying out. Whatever method the zerocopy pipes use is probably what I'm looking for though. -Jer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Mapping a piece of one process' addrspace to another?
Marcelo Tosatti writes:
>On Wed, 7 Mar 2001, Alexander Viro wrote:
>> You are reinventing the wheel.
>> man ptrace (see PTRACE_{PEEK,POKE}{TEXT,DATA} and PTRACE_{ATTACH,CONT,DETACH})
>
>With ptrace data will be copied twice. As far as I understood, Jeremy
>wants to avoid that.
Yes - I've been looking at the sys_ptrace code and it seems that it
does two copies through the kernel (but, using access_process_vm
instead of copy_from_user -- I'm not sure how they differ). I'm
trying to reduce the number of copies by giving one process a pointer
into another process's address space.
Right now, my code looks something like this: (it might make more
sense if you know that I've written a framework for writing user-space
device drivers... I'm going to be releasing it soon, hopefully after I
resolve this performance problem. Or maybe before, if it's hard.)
Process X: (any arbitrary process)
read(fd, my_local_buffer);
Kernel:
[notifies process Y that X needs data]
Process Y: (the userspace device driver)
memcpy(my_local_buffer, data_destined_for_process_x);
write(fd, my_local_buffer);
Kernel (in sys_write:)
copy_from_user(kernel_buffer, Y's my_local_buffer);
copy_to_user(X's my_local_buffer, kernel_buffer);
Now, this all works fine, but it's slower than I'd like. I used SGI's
kernprof (oss.sgi.com/projects/kernprof) and found that the kernel was
spending most of its time (like 70%) in copy_to_user and
copy_from_user. So, I am hoping to make this all go faster, while
hopefully preserving correctness, by changing to something like this:
Process X:
read(fd, my_local_buffer);
Kernel:
[maps X's my_local_buffer to Y's address space]
[notifies process Y that X needs data, and sends along a
pointer to write data to, or a handle usable by shmat,
or something]
Process Y:
memcpy(X's my_local_buffer, data_destined_for_process_x);
If I'm lucky we can avoid both copy_to_user and copy_from_user.
This would be easy if X was a "cooperative" process because we could
just set up a shared memory segment between the two processes. The
problem is that X is not cooperative -- it can be any existing
program.
Regards,
Jeremy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Mapping a piece of one process' addrspace to another?
Marcelo Tosatti writes:
On Wed, 7 Mar 2001, Alexander Viro wrote:
You are reinventing the wheel.
man ptrace (see PTRACE_{PEEK,POKE}{TEXT,DATA} and PTRACE_{ATTACH,CONT,DETACH})
With ptrace data will be copied twice. As far as I understood, Jeremy
wants to avoid that.
Yes - I've been looking at the sys_ptrace code and it seems that it
does two copies through the kernel (but, using access_process_vm
instead of copy_from_user -- I'm not sure how they differ). I'm
trying to reduce the number of copies by giving one process a pointer
into another process's address space.
Right now, my code looks something like this: (it might make more
sense if you know that I've written a framework for writing user-space
device drivers... I'm going to be releasing it soon, hopefully after I
resolve this performance problem. Or maybe before, if it's hard.)
Process X: (any arbitrary process)
read(fd, my_local_buffer);
Kernel:
[notifies process Y that X needs data]
Process Y: (the userspace device driver)
memcpy(my_local_buffer, data_destined_for_process_x);
write(fd, my_local_buffer);
Kernel (in sys_write:)
copy_from_user(kernel_buffer, Y's my_local_buffer);
copy_to_user(X's my_local_buffer, kernel_buffer);
Now, this all works fine, but it's slower than I'd like. I used SGI's
kernprof (oss.sgi.com/projects/kernprof) and found that the kernel was
spending most of its time (like 70%) in copy_to_user and
copy_from_user. So, I am hoping to make this all go faster, while
hopefully preserving correctness, by changing to something like this:
Process X:
read(fd, my_local_buffer);
Kernel:
[maps X's my_local_buffer to Y's address space]
[notifies process Y that X needs data, and sends along a
pointer to write data to, or a handle usable by shmat,
or something]
Process Y:
memcpy(X's my_local_buffer, data_destined_for_process_x);
If I'm lucky we can avoid both copy_to_user and copy_from_user.
This would be easy if X was a "cooperative" process because we could
just set up a shared memory segment between the two processes. The
problem is that X is not cooperative -- it can be any existing
program.
Regards,
Jeremy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Mapping a piece of one process' addrspace to another?
Alexander Viro writes: On Wed, 7 Mar 2001, Jeremy Elson wrote: Right now, my code looks something like this: (it might make more sense if you know that I've written a framework for writing user-space device drivers... I'm going to be releasing it soon, hopefully after I resolve this performance problem. Or maybe before, if it's hard.) Ugh. Why not make that a named pipe and use zerocopy stuff for pipes? I.e. why bother with making it look like a character device rather than a FIFO? Well, because it's a character device :-). i.e,. the framework allows you to write a userspace program that services callbacks for character devices. Inside the kernel, all open()/release()/ioctl()/etc calls for the device are proxied out to userspace where a library calls a userspace callback, and the result goes back to the kernel where it is then returned to the calling process. The problem is just that to return data (instead of just a retval), as is needed for read and some ioctls, it leads to 3 copies as I described earlier. BTW, where are the zerocopy patches for pipes? Maybe I'm missing something but it seems that pipes inside the kernel are still implememented by copying into the kernel and then copying out. Whatever method the zerocopy pipes use is probably what I'm looking for though. -Jer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Mapping a piece of one process' addrspace to another?
Alexander Viro writes: Erm. If ioctls are device-specific - the program is already bound to specific driver. If they are for class of devices (and if I guessed right that's the case you are interested in - sound, isn't it?) we could let the stub driver in kernel open two pipes and redirect read()/write() on device to the first one turn ioctls into read()/write() on the second. That way you can get userland programs serving that stuff with no magic required. One problem, in addition to the points Abramo made, is that there's no metadata that goes along with the data you're writing to the pipe. This is fine as long as there's only one process reading, but in the case of a single driver serving multiple instances of an open file, there has to be some way for the userspace driver to communicate to the kernel which open file needs to get the data. A similar problem is that metadata needs to accompany the read request when the userspace driver gets it (i.e., current file position, file flags, size of the read that was requested, etc.) Although, that data might be transmitted on the OOB channel. Also, even though my framework right now only does character devices, it's a pretty simple extension to support userspace block devices and network devices as well. In these cases I think using a pipe gets more and more complicated. From reading all the responses to the thread (thanks, everyone, for your useful comments), it sounds like the best thing to do is use Manfred's zerocopy pipe code as a model and implement something similar in my framework. It's not really that much code anyway so it's not much of a waste reimplementing it. And, I think reimplementing those 30 lines will be much simpler than trying to manage 2 parallel channels. If the zerocopy patch becomes part of the kernel anyway, it gets even simpler, since I can probably just call pio_copy_to_user instead of copying it. Regards, Jer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Mapping a piece of one process' addrspace to another?
Greetings, Is there some way to map a piece of process X's address space into process Y, without X's knowledge or cooperation? (The non-cooperating nature of process X is why I can't use plain old shared memory.) Put another way, I need to grant Process Y permission to write into a private buffer owned by process X. X doesn't know this is happening, and I don't know where X's buffer even lives (X's stack, heap, etc.). X just passes a pointer to the kernel via a system call (e.g., like sys_read). In the system I currently have implemented, Y writes a buffer to the kernel, and the kernel relays it to X on behalf of Y. But, for performance reasons, I want to try to get Y to write its data directly to X instead. X might be any process calling read() (e.g., "cat"), but Y is in collusion with the kernel. If this is possible at all, is it also possible on a granularity down to one byte (as opposed to an entire page)? Sorry if this seems like a strange thing to do - but, I hope to document and release my code soon, in which case its purpose should be clearer :-). Regards, Jeremy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Mapping a piece of one process' addrspace to another?
Greetings, Is there some way to map a piece of process X's address space into process Y, without X's knowledge or cooperation? (The non-cooperating nature of process X is why I can't use plain old shared memory.) Put another way, I need to grant Process Y permission to write into a private buffer owned by process X. X doesn't know this is happening, and I don't know where X's buffer even lives (X's stack, heap, etc.). X just passes a pointer to the kernel via a system call (e.g., like sys_read). In the system I currently have implemented, Y writes a buffer to the kernel, and the kernel relays it to X on behalf of Y. But, for performance reasons, I want to try to get Y to write its data directly to X instead. X might be any process calling read() (e.g., "cat"), but Y is in collusion with the kernel. If this is possible at all, is it also possible on a granularity down to one byte (as opposed to an entire page)? Sorry if this seems like a strange thing to do - but, I hope to document and release my code soon, in which case its purpose should be clearer :-). Regards, Jeremy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
