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:	Fri, 14 Nov 2008 19:06:16 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Mikulas Patocka <mpatocka@...hat.com>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, rml@...h9.net,
	Alasdair G Kergon <agk@...hat.com>,
	Milan Broz <mbroz@...hat.com>
Subject: Re: Active waiting with yield()

> * driver unload --- check the count of outstanding requests and call 
> yield() repeatedly until it goes to zero, then unload.

Use a wakeup when the request count hits zero

> * reduced size of data structures (and reduced cache footprint for the hot 
> path that actually processes requests)

The CPU will predict the non-wakeup path if that is normal. You can even
make the wakeup use something like

	if (exiting & count == 0)

to get the prediction righ

> The downside of yield is slower unloading of the driver by few tens of 
> miliseconds, but the user doesn't really care about fractions of a second 
> when unloading drivers.

And more power usage, plus extremely rude behaviour when virtualising.

There are cases you have to use cpu_relax/spins or yield simply because
the hardware doesn't feel like providing interrupts when you need them,
but for the general case its best to use proper sleeping.

Remember also you can use a single wait queue for an entire driver for
obscure happenings like unloads.

Alan

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