http://dovecot.org/tmp/concurrency.c I'd want to know what results this program gives with different systems. Please test and reply (but don't bother if someone already replied with the same OS+result). I expect it to print: - SMP kernels: "page size cut" once in a while - UP (uniprocessor) kernels: Nothing - The most important thing is that it never prints "broken data" It might take a while for it to print anything. With my computer it takes anything from a few seconds to a minute or so. See the file itself for compiling/running instructions. So far I've tested only with Linux 2.6.21 x86-64/SMP and a slow Solaris/Sparc/UP. If you're interested in knowing what this is about: Dovecot writes to dovecot.index.log files by first writing the transaction with its size being 0. After that it writes the 4 size bytes again (using a bit special format with all bytes ORed with 0x80). I expected that when another process is read()ing the file and it notices the size being valid (all bytes having 0x80) that the whole transaction could always be read. But looks like if the size happens to be just before a memory page boundary, it's possible that the updated size is read, but the rest of the transaction isn't. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20070620/4b9cc4b4/attachment-0002.bin>
If there is no output, whats the longest you want us to wait while it runs? How much do you care about unique OS/arch/cpu/fs combinations (what factors shouldn't matter)? I assume you want just one reader and one writer, started in the order listed in the source? I currently have it running on SMP(quad) FreeBSD 6.2-STABLE amd64 Sat Jun 16 2007 on both ufs2 and nfs to our NetApp, and UP FreeBSD 6.2-STABLE i386 Tue Jan 16 2007 on ufs2, maybe some more systems after I send this mail, and a little later I can try it on UP FreeBSD 7 with zfs. The ones I already have running for a few minutes have printed nothing so far. On Wed, Jun 20, 2007 at 02:41:42AM +0300, Timo Sirainen wrote: http://dovecot.org/tmp/concurrency.c I'd want to know what results this program gives with different systems. Please test and reply (but don't bother if someone already replied with the same OS+result). I expect it to print: - SMP kernels: "page size cut" once in a while - UP (uniprocessor) kernels: Nothing - The most important thing is that it never prints "broken data" It might take a while for it to print anything. With my computer it takes anything from a few seconds to a minute or so. See the file itself for compiling/running instructions. So far I've tested only with Linux 2.6.21 x86-64/SMP and a slow Solaris/Sparc/UP. If you're interested in knowing what this is about: Dovecot writes to dovecot.index.log files by first writing the transaction with its size being 0. After that it writes the 4 size bytes again (using a bit special format with all bytes ORed with 0x80). I expected that when another process is read()ing the file and it notices the size being valid (all bytes having 0x80) that the whole transaction could always be read. But looks like if the size happens to be just before a memory page boundary, it's possible that the updated size is read, but the rest of the transaction isn't.
NetBSD 3.1 (GENERIC) No output, as expected after about 15min running. Daniel. Timo Sirainen wrote:> http://dovecot.org/tmp/concurrency.c > > I'd want to know what results this program gives with different systems. > Please test and reply (but don't bother if someone already replied with > the same OS+result). I expect it to print: > > - SMP kernels: "page size cut" once in a while > - UP (uniprocessor) kernels: Nothing > - The most important thing is that it never prints "broken data" > > It might take a while for it to print anything. With my computer it > takes anything from a few seconds to a minute or so. See the file itself > for compiling/running instructions. > > So far I've tested only with Linux 2.6.21 x86-64/SMP and a slow > Solaris/Sparc/UP. > > If you're interested in knowing what this is about: > > Dovecot writes to dovecot.index.log files by first writing the > transaction with its size being 0. After that it writes the 4 size bytes > again (using a bit special format with all bytes ORed with 0x80). > > I expected that when another process is read()ing the file and it > notices the size being valid (all bytes having 0x80) that the whole > transaction could always be read. But looks like if the size happens to > be just before a memory page boundary, it's possible that the updated > size is read, but the rest of the transaction isn't. > >
On Wed, Jun 20, 2007 at 02:41:42AM +0300, Timo Sirainen wrote:> http://dovecot.org/tmp/concurrency.c > > I'd want to know what results this program gives with different systems. > Please test and reply (but don't bother if someone already replied with > the same OS+result). I expect it to print: > > - SMP kernels: "page size cut" once in a while > - UP (uniprocessor) kernels: Nothing > - The most important thing is that it never prints "broken data" > > It might take a while for it to print anything. With my computer it > takes anything from a few seconds to a minute or so. See the file itself > for compiling/running instructions.Hi, hope it isn't too unexpected but it prints nothing for me neither in the UP nor SMP case, just: > ./concurrency writing, page size = 4096 > ./concurrency 1 reading, page size = 4096 UP is a stable setup with 'FreeBSD 6.2-RELEASE-p1 i386' (32bit) and SMP a rather adventurous setup with 'FreeBSD 7.0-CURRENT amd64' (64bit). I ran the code for more than 10 minutes on each machine. -- Sascha
Timo Sirainen said the following on 20/6/2007 1:41:> http://dovecot.org/tmp/concurrency.cAMD Athlon(tm) 64 Processor 2800+ 2.6.21-1.3228.fc7 (Fedora 7) Noting. Intel(R) Pentium(R) 4 CPU 3.06GHz w/HyperThreading 2.6.9-42.0.3.ELsmp (Red Hat) page size cut after a couple of minutes Ciao, luigi -- / +--[Luigi Rosa]-- \ (1) Everything depends. (2) Nothing is always. (3) Everything is sometimes.
Hi Timo, Timo Sirainen wrote:> http://dovecot.org/tmp/concurrency.c > > I'd want to know what results this program gives with different systems. > Please test and reply (but don't bother if someone already replied with > the same OS+result). I expect it to print: > > - SMP kernels: "page size cut" once in a while > - UP (uniprocessor) kernels: Nothing > - The most important thing is that it never prints "broken data" >Linux 2.6.20-16-server (SMP), Core 2 Duo E6600: Only one reader: No output Three readers: After a few minutes "Page size cut" printed by one of them Linux 2.6.18-028stab027 (UP), Athlon 64 3700+: Never outputs anything. Regards, Philipp
Hi Timo,> http://dovecot.org/tmp/concurrency.c[cut]> So far I've tested only with Linux 2.6.21 x86-64/SMP and a slow > Solaris/Sparc/UP.One writer and three readers ran for 30 minutes on Solaris 10 without printing anything. The box is an UltraSparc IIIi dual proc, and the FS on the partition is UFS. Greg
Quoting Timo Sirainen:> http://dovecot.org/tmp/concurrency.c > > I'd want to know what results this program gives with different systems. > Please test and reply (but don't bother if someone already replied with > the same OS+result). I expect it to print:Dual Pentium III 1133MHz: one "page size cut" every few minutes Dual Xeon 2.40GHz (with HT -> 4 virtual CPUs): "page size cut" immediatly and constantly. Both on Linux 2.6.13.
On Tue, June 19, 2007 7:41 pm, Timo Sirainen <tss at iki.fi> said:> http://dovecot.org/tmp/concurrency.c > > I'd want to know what results this program gives with different systems. > Please test and reply (but don't bother if someone already replied with > the same OS+result). I expect it to print:./concurrency writing, page size = 4096 ./concurrency 1 reading, page size = 4096 Red Hat ES3 (2.4.21-32.0.1.EL) athlon i386
On Wed, 2007-06-20 at 02:41 +0300, Timo Sirainen wrote:> http://dovecot.org/tmp/concurrency.c > > I'd want to know what results this program gives with different systems. > Please test and reply (but don't bother if someone already replied with > the same OS+result). I expect it to print: > > - SMP kernels: "page size cut" once in a whileHmm. This happens even if file is being locked. So I think this is a Linux bug.. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20070620/2a489b80/attachment-0002.bin>
Timo Sirainen wrote:> On Wed, 2007-06-20 at 02:41 +0300, Timo Sirainen wrote: >> http://dovecot.org/tmp/concurrency.cWorks on dual processor running latest Fedora 7: net1#uname -a Linux net1.coolsurf.com 2.6.21-1.3228.fc7 #1 SMP \ Tue Jun 12 14:56:37 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux -- Like feeling your best ever, all day, every day? Here's how... Your simple secrets are here - http://RadicalHealth.com
OS: CentOS 4.5 (Final) (RHEL4 clone) $ /usr/bin/time -f "total time: %E\ni/o waits: %w\n" ./concurrency writing, page size = 4096 Command terminated by signal 2 total time: 10:41.53 i/o waits: 312177 $ /usr/bin/time -f "total time: %E\ni/o waits: %w\n" ./concurrency 1 reading, page size = 4096 page size cut Command terminated by signal 2 total time: 10:39.67 i/o waits: 314930 Machine: $ uname -srvmpoi Linux 2.6.9-42.0.10.ELsmp #1 SMP Tue Feb 27 10:11:19 EST 2007 i686 i686 i386 GNU/Linux $ cat /proc/cpuinfo | egrep "(processor|model name)" processor : 0 model name : Intel(R) Xeon(R) CPU 5120 @ 1.86GHz processor : 1 model name : Intel(R) Xeon(R) CPU 5120 @ 1.86GHz processor : 2 model name : Intel(R) Xeon(R) CPU 5120 @ 1.86GHz processor : 3 model name : Intel(R) Xeon(R) CPU 5120 @ 1.86GHz Timo Sirainen wrote:> http://dovecot.org/tmp/concurrency.c > > I'd want to know what results this program gives with different systems. > Please test and reply (but don't bother if someone already replied with > the same OS+result). I expect it to print: > > - SMP kernels: "page size cut" once in a while > - UP (uniprocessor) kernels: Nothing > - The most important thing is that it never prints "broken data" > > It might take a while for it to print anything. With my computer it > takes anything from a few seconds to a minute or so. See the file itself > for compiling/running instructions. > > So far I've tested only with Linux 2.6.21 x86-64/SMP and a slow > Solaris/Sparc/UP. > > If you're interested in knowing what this is about: > > Dovecot writes to dovecot.index.log files by first writing the > transaction with its size being 0. After that it writes the 4 size bytes > again (using a bit special format with all bytes ORed with 0x80). > > I expected that when another process is read()ing the file and it > notices the size being valid (all bytes having 0x80) that the whole > transaction could always be read. But looks like if the size happens to > be just before a memory page boundary, it's possible that the updated > size is read, but the rest of the transaction isn't. >-- Troy Engel | Systems Engineer Fluid, Inc | http://www.fluid.com
On Wed, 2007-06-20 at 02:41 +0300, Timo Sirainen wrote:> http://dovecot.org/tmp/concurrency.cYou can forget about this for now. There was one bug in it and with a couple of changes I can't break it in my own system either anymore. Wonder why I'm seeing similar problems in Dovecot v1.1 code.. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20070620/c305e8c2/attachment-0002.bin>
Am Mittwoch, 20. Juni 2007 schrieb Timo Sirainen:> http://dovecot.org/tmp/concurrency.cMh... "19:51:35 FEHLER 404: Not Found." I just wanted to test it using Linux 2.6.21 on my Core2 Duo T7200 running Debian Unstable... Does anyone still have the file? Greetings, Gunter -- *** Powered by AudioScrobbler --> http://www.last.fm/user/Interneci/ *** 18:40 | Xandria - Vampire 18:36 | Xandria - Save My Life 23:14 | Regicide - Perfect strings 23:05 | Regicide - An Embracing Space Part III: Eclipsing Lights *** PGP-Verschl?sselung bei eMails erw?nscht :-) *** PGP: 0x1128F25F *** -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: <http://dovecot.org/pipermail/dovecot/attachments/20070620/f8ca7cff/attachment-0002.bin>
On Wed, 2007-06-20 at 02:41 +0300, Timo Sirainen wrote:> - SMP kernels: "page size cut" once in a whileexactly what happens with Linux 2.6.22-rc5 on my quad powermac johannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20070620/164c3d28/attachment-0002.bin>