> I have the same question/problem as this guy, and totally don't
> understand the /proc filesystem comment.
I don't understand that, either.
> Any ideas? This would be a **huge** performance boost for my
> module, http://toronto.qenesis.com/Sam/srr.html
>
> Peformance is dominated by the costs of the memory copies, for any
> sizeable messages, and I could halve that cost, since the module
> design is such that there is always a reader blocked and waiting
> when the writer does the write.
After some investigation, this is my current impression of the
Linux kernel:
o If you are inside the kernel, you either have exactly one user
level program context or none (e.g. in a bottom half of an IRQ
handler)
o A user level context means that the complete programs address
space is accessible from the kernel (the MMU setup "fits" to that
user process)
o There is no way that all memory regions of two processes are
mapped at the same time.
=> to my knowledge, there is no way that the kernel can directly
copy data from process A to process B, when the data origin is
unrestricted
Some RTOS (real time operating systems) use a trick: they map the
memory space of each user process somewhere in the kernel space.
This is fine as long as the sum of concurrently running programs
multiplied with the programs used memory (physical+swap) usage is
much lower than the virtual address space (e.g. 4 GB).
For a RTOS with no swap and a typical total physical memsize of
<<128MB, this will work just fine.
To my knowledge, there are two possible solutions to avoid memory
copying:
1) user level programs use shared memory, so they don't need the
kernel at all
2) handing over of memory (see the Doors stuff,
http://www.rampant.org/doors/).
I looked at both, and they have some major drawbacks (depending on
what you want to do):
1) as of today, Linux doesn't support mutexes between processes
(glibc mutexes work only within a process). This is mainly because
process shared mutexes would require kernel support, and the kernel
doesn't support that
(http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html).
2) the Doors implementation needs a patched kernel
Bye,
Jürgen
> Date: Sun, 02 May 1999 15:04:48 -0400
> From: Andrew Thomas <andrew@cogent.ca>
> To: sam@cogent.ca
> Subject: Copy from one process to another
>
> This is a strange question/answer that might shed a tiny amount of
> light. I sure don't understand the connection.
>
> >Hi,
> >
> > in my first kernel-related project, i want to copy data in the
> > kernel from one >process to another.
> >
> > I have the start point/size of the user-level buffers, but i
> > found no way to do a >_direct_ copy.
> >
> > The copy takes place in a write() call of a character device
> > driver, the >source/size is the write buffer/size, the
> > destinition is a other process, currently blocking in its read
> > method.
> >
> > Of course, i could do a kmalloc, copy to kernel, wake up the
> > read, copy from the >kmalloc'd area, kfree the area, but ... that
> > is too much overhead.
>
> Use the /Proc file system
>
> Forum: The Linux Kernel Hackers' Guide
> Re: How can the kernel copy directly data from one process to
> another process? (Jürgen Zeller)
> Keywords: direct copy, user space, kernel space
> Date: Mon, 22 Jun 1998 16:15:21 GMT
> From: <marty@twsu.campus.mci.net>
>
> The /proc file system uses a directory for each pid. Do a man 5
> proc on linux machine to find out more? Bye, Marty.
>
--- Juergen Zeller, zeller@rupert.franken.de, http://www.franken.de/users/rupert/zeller ------- - - - - - - - - - - - - - - - - - - - - --------- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/