From: george anzinger <george@mvista.com>
To: Andrea Arcangeli <andrea@suse.de>
Cc: "Robert Love" <rml@tech9.net>,
"Dieter Nützel" <Dieter.Nuetzel@hamburg.de>,
"Andrew Morton" <akpm@zip.com.au>, "Chris Mason" <mason@suse.com>,
"Beau Kuiper" <kuib-kl@ljbc.wa.edu.au>,
"Linux Kernel List" <linux-kernel@vger.kernel.org>,
"ReiserFS List" <reiserfs-list@namesys.com>
Subject: Re: [PATCH] Significant performace improvements on reiserfs systems
Date: Thu, 20 Sep 2001 17:37:46 -0700 [thread overview]
Message-ID: <3BAA8BDA.5EED2879@mvista.com> (raw)
In-Reply-To: <20010920170812.CCCACE641B@ns1.suse.com> <3BAA29C2.A9718F49@zip.com.au> <1001019170.6090.134.camel@phantasy> <200109202112.f8KLCXG16849@zero.tech9.net> <1001024694.6048.246.camel@phantasy> <20010921003742.I729@athlon.random> <1001026597.6048.278.camel@phantasy> <20010921011514.M729@athlon.random>
Andrea Arcangeli wrote:
>
> On Thu, Sep 20, 2001 at 06:56:04PM -0400, Robert Love wrote:
> > On Thu, 2001-09-20 at 18:37, Andrea Arcangeli wrote:
> > > On Thu, Sep 20, 2001 at 06:24:48PM -0400, Robert Love wrote:
> > > >
> > > > if (current->need_resched && current->lock_depth == 0) {
> > > > unlock_kernel();
> > > > lock_kernel();
> > > > }
> >
> > > nitpicking: the above is fine but it isn't complete, it may work for
> > > most cases but for a generic function it would be better implemented
> > > similarly to release_kernel_lock_save/restore so you take care of
> > > lock_depth > 0 too:
> >
> > Let me explain a little about the patch, and then I am interested in if
> > your opinion changes.
> >
> > When unlock_kernel() is called, the preemption code will be enabled and
> > check if the preemption count is non-zero -- its handled just like a
>
> All I'm saying is that you should check for >= 0, not == 0.
>
> But anwyays it's pretty depressing to see such a costly check needed to
> get latency right with the preemptive kernel approch, with
> non-preemptive kernel we'd need to just check need_resched and a call
> schedule in the unlikely case so it would be even lighter :) and no
> fixed costs in UP spinlocks, per-cpu datastrctures etc... The point of
> preemptive kernel would be just to prevent us to put such kind of
> explicit (costly) checks in the code. My theory was that the cpu-costly
> loops are mostly protected by some lock anyways and the fact you're
> writing such horrid (but helpful) code is a kind of proof.
>
Actually, I rather think that the problem is lock granularity. These
issues are present in the SMP systems as well. A good solution would be
one that shortened the spinlock time. No horrid preempt code, just
tight fast code.
And the ones to address these issues are the owners of the code. Those
who want the lower latency are left, thur lack of knowledge and time,
with crude tools like the conditional_schedule().
George
next prev parent reply other threads:[~2001-09-21 0:39 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20010920170812.CCCACE641B@ns1.suse.com>
2001-09-20 17:19 ` [PATCH] Significant performace improvements on reiserfs systems Chris Mason
2001-09-20 17:39 ` Andrew Morton
2001-09-20 20:52 ` Robert Love
2001-09-20 21:11 ` Dieter Nützel
[not found] ` <200109202112.f8KLCXG16849@zero.tech9.net>
2001-09-20 22:24 ` Robert Love
2001-09-20 22:37 ` Andrea Arcangeli
2001-09-20 22:56 ` Robert Love
2001-09-20 23:15 ` Andrea Arcangeli
2001-09-20 23:41 ` Robert Love
2001-09-21 0:37 ` george anzinger [this message]
2001-09-21 1:20 ` Andrew Morton
2001-09-21 3:14 ` Robert Love
2001-09-21 9:32 ` [reiserfs-list] " Nikita Danilov
2001-09-21 12:18 ` Alan Cox
2001-09-21 12:31 ` Nikita Danilov
2001-09-23 23:49 ` Rusty Russell
2001-09-20 18:47 ` Andrea Arcangeli
2001-09-20 18:58 ` Andrew Morton
2001-09-20 19:13 ` Andrea Arcangeli
[not found] <200109201708.f8KH8sG15617@zero.tech9.net>
2001-09-20 20:48 ` Robert Love
2001-09-20 17:08 Dieter Nützel
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=3BAA8BDA.5EED2879@mvista.com \
--to=george@mvista.com \
--cc=Dieter.Nuetzel@hamburg.de \
--cc=akpm@zip.com.au \
--cc=andrea@suse.de \
--cc=kuib-kl@ljbc.wa.edu.au \
--cc=linux-kernel@vger.kernel.org \
--cc=mason@suse.com \
--cc=reiserfs-list@namesys.com \
--cc=rml@tech9.net \
/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