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]
Message-ID: <alpine.DEB.1.10.0906151101580.23995@gentwo.org>
Date:	Mon, 15 Jun 2009 11:05:42 -0400 (EDT)
From:	Christoph Lameter <cl@...ux-foundation.org>
To:	Pekka Enberg <penberg@...helsinki.fi>
cc:	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, kamezawa.hiroyu@...fujitsu.com,
	lizf@...fujitsu.com, mingo@...e.hu, npiggin@...e.de,
	yinghai@...nel.org, benh@...nel.crashing.org
Subject: Re: [GIT PULL v2] Early SLAB fixes for 2.6.31

On Mon, 15 Jun 2009, Pekka Enberg wrote:

> > Dont do it there. Only modify the slow path.
> >
> > Look at __might_sleep(). It already has an exception for system_state !=
> > RUNNING. If it still triggers then add to the condition there.
>
> But does this matter? When the debugging options are turned off, there
> are no users for "real_gfp" and thus GCC optimizes everything away. For
> debugging configs, the extra cacheline load doesn't matter, does it?

It cleaner to have the fastpath as small as possible. Having unused
variables in there is a bit confusing.

Also the path is performance critical. That may not matter for the debug
case in some sitiations. But there are people that keep the debugging
options on. Better to limit the impact as much as possible.

And the "extra cacheline load does not matter" reasoning can only be
applied so many times. An extra cacheline load increases the cache foot
print of the fast path after all.





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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ