mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: kumon@flab.fujitsu.co.jp
To: Andrew Morton <andrewm@uow.edu.au>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>,
	"kumon@flab.fujitsu.co.jp" <kumon@flab.fujitsu.co.jp>,
	Linus Torvalds <torvalds@transmeta.com>,
	linux-kernel@vger.kernel.org
Cc: kumon@flab.fujitsu.co.jp
Subject: locks.c: removal of semaphores
Date: Tue, 7 Nov 2000 12:15:16 +0900	[thread overview]
Message-ID: <200011070315.MAA15183@asami.proc.flab.fujitsu.co.jp> (raw)
In-Reply-To: <3A053B05.2AE5D4EB@uow.edu.au>
In-Reply-To: <3A053B05.2AE5D4EB@uow.edu.au>

Andrew,
I got 5250 Req/s with your locks-sem.patch on normal Apache.
It is good performance on normal Apache.

Andrew Morton writes:
 > Kouichi, could you please test the performance of this on
 > your 8-way with Apache+fcntl serialisation? (the normal
 > Apache).  Please use 2.4.0-test10-pre5, not 2.4.0-test10.
 > Something has gone funny with test10 and I'm getting much
 > lower rates.

Followings are the recent data with/without serialization.

			w/ serialize	w/o serialize
240t10pre5		2237		5358
240t10pre5+P2		5253		5355**
240t10pre5+P3		---		NG
240t10pre5+locksem	5250		---
	**: once we found deadlock
	NG: cannot complete measurement
	--: we've not measured.

Normal apache on various kernel setting as follows:

> test8			5287 <-- best performance
> test10-pre5+P2	5258
> 240t10pre5+locksem	5250
> test9+P2		5243
> test9+mypatch		5192 <-- a little bit worse
> test10-pre5+P1	5187
> test1			3702 <-- no good scalability
> test10-pre5		2255 <-- negative scalability
> test9			2193


We also did durability test of 2.4.0-test10-pre5.  Unfortunately
enough, we didn't successfully complete the test of Apache w/o
serialization (-DSINGLE_LISTEN_UNSERIALIZED_ACCEPT), it couldn't
continue to run for a night.  The kernel got complete deadlock.

The message is:
"Unable to handle kernel NULL pointer dereference NMI watchdog detected LOCKUP on CPU1."

Yes, obviously it's not Andrew's problem, that is genuine test10-pre5.

Hidden bugs are awakened by removing serialization.

If the bug is same as what I observed, It is NULL pointer dereference
on run-queue list.
--
Computer Systems Laboratory, Fujitsu Labs.
kumon@flab.fujitsu.co.jp
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

       reply	other threads:[~2000-11-07  3:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3A053B05.2AE5D4EB@uow.edu.au>
2000-11-07  3:15 ` kumon [this message]
2000-11-07  7:24   ` Andrew Morton
2000-11-07 17:57 ` Trond Myklebust

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=200011070315.MAA15183@asami.proc.flab.fujitsu.co.jp \
    --to=kumon@flab.fujitsu.co.jp \
    --cc=andrewm@uow.edu.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    --cc=trond.myklebust@fys.uio.no \
    /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

all inboxes | Powered by JetHome®