Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 10 Sep 2003 12:14:53 +0200 | From | Arjan van de Ven <> | Subject | Re: Efficient IPC mechanism on Linux |
| |
On Wed, Sep 10, 2003 at 12:09:21PM +0200, Luca Veraldi wrote: > > For fun do the measurement on a pIV cpu. You'll be surprised. > > The microcode "mark dirty" (which is NOT a btsl, it gets done when you do > a write > > memory access to the page content) result will be in the 2000 to 4000 > range I > > predict. > > I'm not responsible for microarchitecture designer stupidity. > If a simple STORE assembler instruction will eat up 4000 clock cycles, > as you say here, well, I think all we Computer Scientists can go home and > give it up now.
I'm saying it can. I don't want to go too deep into an arguement about microarchitectural details, but my point was that a memory copy of a page is NOT super expensive relative to several other effects that have to do with pagetable manipulations.
> > if you change a page table, you need to flush the TLB on all other cpus > > that have that same page table mapped, like a thread app running > > on all cpu's at once with the same pagetables. > > Ok. Simply, this is not the case in my experiment. > This does not apply. > We have no threads. But only detached process address spaces. > Threads are a bit different from processes.
but the pipe code cannot know this so it has to do a cross cpu invalidate.
> > why would you need a global lock for copying memory ? > > System call sys_write() calls > locks_verify_area() which calls > locks_mandatory_area() which calls > lock_kernel()
and... which is also releasing it before the copy
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |