linux-kernel - Re: 2.6.24-rc6-mm1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 2 Jan 2008 22:12:28 +1100
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Andrew Morton <akpm@...ux-foundation.org>,
	trem <tremyfr@...oo.fr>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: 2.6.24-rc6-mm1

On Wednesday 02 January 2008 22:01, Peter Zijlstra wrote:
> On Wed, 2008-01-02 at 21:31 +1100, Nick Piggin wrote:
> > On Monday 31 December 2007 00:10, Ingo Molnar wrote:
> > > * Herbert Xu <herbert@...dor.apana.org.au> wrote:
> > > > > Ingo, it's not good that we have cond_resched() definitions
> > > > > conditionally duplicated in kernel.h - that's increasing the risk
> > > > > of bugs like this one.
> > > >
> > > > Actually, why do we even have cond_resched when real preemption is
> > > > on? It seems to be a waste of space and time.
> > >
> > > due to the BKL. cond_resched() in BKL code breaks up BKL latencies.
> > >
> > > i dont mind not doing that though - we should increase the pain for BKL
> > > users, so that subsystems finally get rid of it altogether.
> > > lock_kernel() use within the kernel is still rampant - there are still
> > > more than 400 callsites to lock_kernel().
> >
> > It would be silly to potentially increase latency in some areas
> > for CONFIG_PREEMPT kernels, though.
> >
> > Better may be to detect when there is CONFIG_PREEMPT and
> > CONFIG_PREEMPT_BKL, and ifdef away the cond_resched in that case
> > (or -- why do we even make CONFIG_PREEMPT_BKL an option? Are there
> > really workloads left where it causes throughput regressions?)
>
> I've seen 1s+ desktop latencies due to PREEMPT_BKL when I was still
> using reiserfs.

Fair enough; so the former ifdefery would be preferable for now then.

> Both reiserfs and tty were fighting for the bkl and massive prio
> inversion ensued. Turning PREEMPT_BKL off made the system usable again.

Are either of those subsystems actually using the BKL to protect against
anything else (than themselves)? It would be sweet to have them use
private mutexes for the job instead (although even then it probably
wouldn't be a straight conversion)...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/