linux-kernel - Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20070731091359.GB15136@elte.hu>
Date:	Tue, 31 Jul 2007 11:13:59 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Kasper Sandberg <lkml@...anurb.dk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	ck@....kolivas.org
Subject: Re: SD still better than CFS for 3d   ?(was Re: 2.6.23-rc1)

* Alan Cox <alan@...rguk.ukuu.org.uk> wrote:

> > code runs under the BKL, and the only other major kernel 
> > infrastructure that has BKL dependencies is the TTY code. Kasper, as 
> > a debugging
> 
> And half the ioctls some of which trigger long code sections.

the tty layer has relatively short BKL latencies, but reiser3 has long 
ones, so those got transposed over to the tty layer, making it all quite 
noticeable to the user.

BKL contention is not a big issue on the desktop _unless_ there's at 
least one workload that creates really long BKL latencies. That 
multiplexes it out to all the other BKL-using subsystems too.

the DRI/DRM BKL use was a problem some time ago, but i think it's now 
using unlocked_ioctl(), correct? All the other ioctls are rare enough to 
not really matter.

with PREEMPT_BKL there's also some sort of random effect of priority 
inversion that makes the actual latencies depend on the scheduler - but 
we dont understand that effect exactly, yet. (hopefully Kasper can help 
us out with that. Peter got rid of his reiser3 partition the moment the 
latencies were traced back to it.)

> For the tty layer I'm waiting for the revoke code to get finished up 
> and move from -mm into Linus tree. At that point the real evil 
> lock_kernel related stuff in the tty layer can switch to using the 
> revoke code for hangup paths and then other bits can be tackled.

oh, wonderful! Alan, you are a true wizard :-) The tty layer is one of 
the very few pieces of kernel code that scares the hell out of me :-)

	Ingo
-
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/