linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Luca Veraldi" <luca.veraldi@katamail.com>
To: "Arjan van de Ven" <arjanv@redhat.com>
Cc: "linux-kernel" <linux-kernel@vger.kernel.org>
Subject: Re: Efficient IPC mechanism on Linux
Date: Wed, 10 Sep 2003 12:09:21 +0200	[thread overview]
Message-ID: <01f801c37783$9ead8960$5aaf7450@wssupremo> (raw)
In-Reply-To: 20030910114414.B14352@devserv.devel.redhat.com

> 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.

> There are things like SMP synchronisation to do, but also
> if the cpu marks a page dirty in the page table, that means the page table
> changes which means the pagetable needs to be marked in the
> PMD. Which means the PMD changes, which means the PGD needs the PMD marked
> dirty. Etc Etc. It's microcode. It'll take several 1000 cycles.

Please, return to the fact.
Modifying the page contents is done by that part of benchmark application we
are not misuring.
That is, the code ***BEFORE*** the zc_send() (write() on pipe or whatever
you choose)
and ***AFTER*** a zc_receive() (or read() from pipe ot whatever else).
This is nice, thanks, but out of our interests.

We are only reading the relocation tables or inserting new entries in it.
Not modifying page contents.

> 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.

> 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()

oops...
global spin_lock locking...

SMP is crying...
But not so much, if the lock is not lasting much, is it right?

THIS IS NOT WHAT WE CALL A SHORT LOCK SECTION:

732 repeat:
733         /* Search the lock list for this inode for locks that conflict
with
734          * the proposed read/write.
735          */
736         for (fl = inode->i_flock; fl != NULL; fl = fl->fl_next) {
737                 if (!(fl->fl_flags & FL_POSIX))
738                         continue;
739                 if (fl->fl_start > new_fl->fl_end)
740                         break;
741                 if (posix_locks_conflict(new_fl, fl)) {
742                         error = -EAGAIN;
743                         if (filp && (filp->f_flags & O_NONBLOCK))
744                                 break;
745                         error = -EDEADLK;
746                         if (posix_locks_deadlock(new_fl, fl))
747                                 break;
748
749                         error = locks_block_on(fl, new_fl);
750                         if (error != 0)
751                                 break;
752
753                         /*
754                          * If we've been sleeping someone might have
755                          * changed the permissions behind our back.
756                          */
757                         if ((inode->i_mode & (S_ISGID | S_IXGRP)) !=
S_ISGID)
758                                 break;
759                         goto repeat;
760                 }
761         }

>From the source code of your Operating System.


  reply	other threads:[~2003-09-10 10:05 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-09 17:30 Efficient IPC mechanism on Linux Luca Veraldi
2003-09-09 21:17 ` Alan Cox
2003-09-09 21:57   ` Luca Veraldi
2003-09-09 23:11     ` Alan Cox
2003-09-10  9:04       ` Luca Veraldi
2003-09-10 12:56         ` Alan Cox
     [not found] ` <20030909175821.GL16080@Synopsys.COM>
     [not found]   ` <001d01c37703$8edc10e0$36af7450@wssupremo>
     [not found]     ` <20030910064508.GA25795@Synopsys.COM>
2003-09-10  9:18       ` Luca Veraldi
2003-09-10  9:23         ` Arjan van de Ven
2003-09-10  9:40           ` Luca Veraldi
2003-09-10  9:44             ` Arjan van de Ven
2003-09-10 10:09               ` Luca Veraldi [this message]
2003-09-10 10:14                 ` Arjan van de Ven
2003-09-10 10:25                   ` Luca Veraldi
2003-09-12 18:41                     ` Timothy Miller
2003-09-12 19:05                       ` Luca Veraldi
2003-09-12 22:37                         ` Alan Cox
2003-09-10 12:50                 ` Alan Cox
2003-09-10 19:16                 ` Shawn
2003-09-10 20:05                 ` Rik van Riel
2003-09-17  9:52                   ` Rik's list of CS challenges Terje Eggestad
2003-09-17 13:40                     ` Alan Cox
2003-09-18  8:26                       ` Helge Hafting
2003-09-10 12:47             ` Efficient IPC mechanism on Linux Alan Cox
2003-09-10 13:56               ` Luca Veraldi
2003-09-10 15:59                 ` Alan Cox
2003-09-10  9:52           ` Jamie Lokier
2003-09-10 10:07             ` Arjan van de Ven
2003-09-10 10:17               ` Luca Veraldi
2003-09-10 10:37               ` Jamie Lokier
2003-09-10 10:41                 ` Arjan van de Ven
2003-09-10 10:54                   ` Luca Veraldi
2003-09-10 10:54                     ` Arjan van de Ven
2003-09-10 11:16                     ` Nick Piggin
2003-09-10 11:30                       ` Luca Veraldi
2003-09-10 11:44                         ` Nick Piggin
2003-09-10 12:14                           ` Luca Veraldi
2003-09-10 12:42                       ` Alan Cox
2003-09-10 10:11             ` Luca Veraldi
2003-09-10 19:24             ` Pavel Machek
2003-09-10 19:40               ` Jamie Lokier
2003-09-10 21:35                 ` Pavel Machek
2003-09-10 22:06                   ` Jamie Lokier
2003-09-10 11:52         ` Alex Riesen
2003-09-10 12:14           ` Luca Veraldi
2003-09-10 12:11             ` Alex Riesen
2003-09-10 12:29               ` Luca Veraldi
2003-09-10 12:28                 ` Alex Riesen
2003-09-10 12:36                   ` Luca Veraldi
2003-09-10 12:36                     ` Alex Riesen
2003-09-10 13:33                     ` Gábor Lénárt
2003-09-10 14:04                       ` Luca Veraldi
2003-09-10 14:21 ` Stewart Smith
2003-09-10 14:39   ` Luca Veraldi
2003-09-10 16:59 ` Andrea Arcangeli
2003-09-10 17:05   ` Andrea Arcangeli
2003-09-10 17:21     ` Luca Veraldi
2003-09-10 17:41       ` Andrea Arcangeli
2003-09-10 17:39   ` Martin Konold
2003-09-10 18:01     ` Andrea Arcangeli
2003-09-10 18:05       ` Martin Konold
2003-09-10 18:31         ` Chris Friesen
2003-09-10 18:08   ` Inappropriate signatures Larry McVoy
2003-09-10 18:52     ` Jamie Lokier
2003-09-10 19:54     ` rsync head? [was inappropriate signatures] Joe Perches
2003-09-13 15:39     ` Inappropriate signatures Pavel Machek
2003-09-13 16:49       ` Larry McVoy
2003-09-09 18:59 Efficient IPC mechanism on Linux Luca Veraldi
2003-09-09 22:15 Luca Veraldi
     [not found] <F71B37536F3B3D4FA521FEC7FCA17933164A@twinsrv.twinox.se>
2003-09-10 10:36 ` Luca Veraldi
     [not found] <E19x3el-0002Fc-Rj@phoenix.hadiko.de>
2003-09-10 12:16 ` Luca Veraldi
2003-09-10 14:53   ` Larry McVoy
     [not found] <fa.h06p421.1s00ojt@ifi.uio.no>
     [not found] ` <fa.gc37hsp.34id89@ifi.uio.no>
     [not found]   ` <E19x47V-0002JG-J8@phoenix.hadiko.de>
2003-09-10 12:45     ` Luca Veraldi
     [not found] <u9j3.1VB.27@gated-at.bofh.it>
     [not found] ` <u9j3.1VB.29@gated-at.bofh.it>
     [not found]   ` <u9j3.1VB.31@gated-at.bofh.it>
     [not found]     ` <u9j3.1VB.25@gated-at.bofh.it>
     [not found]       ` <ubNY.5Ma.19@gated-at.bofh.it>
     [not found]         ` <uc79.6lg.13@gated-at.bofh.it>
     [not found]           ` <uc7d.6lg.23@gated-at.bofh.it>
     [not found]             ` <uch0.6zx.17@gated-at.bofh.it>
     [not found]               ` <ucqs.6NC.3@gated-at.bofh.it>
     [not found]                 ` <ucqy.6NC.19@gated-at.bofh.it>
     [not found]                   ` <udmB.8eZ.15@gated-at.bofh.it>
     [not found]                     ` <udPF.BD.11@gated-at.bofh.it>
     [not found]                       ` <3F5F37CD.6060808@softhome.net>
2003-09-10 15:28                         ` Luca Veraldi
2003-09-10 18:41 Manfred Spraul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='01f801c37783$9ead8960$5aaf7450@wssupremo' \
    --to=luca.veraldi@katamail.com \
    --cc=arjanv@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).