linux-kernel - Re: [linux-usb-devel] [4/4] 2.6.23-rc3: known regressions

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.LFD.0.999.0708202316430.30176@woody.linux-foundation.org>
Date:	Mon, 20 Aug 2007 23:25:13 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Arjan van de Ven <arjan@...radead.org>
cc:	David Brownell <david-b@...bell.net>,
	Michal Piotrowski <michal.k.k.piotrowski@...il.com>,
	linux-usb-devel@...ts.sourceforge.net, Greg KH <gregkh@...e.de>,
	LKML <linux-kernel@...r.kernel.org>,
	"Stuart_Hayes@...l.com" <Stuart_Hayes@...l.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Daniel Exner <dex@...gonslave.de>
Subject: Re: [linux-usb-devel] [4/4] 2.6.23-rc3: known regressions

On Mon, 20 Aug 2007, Arjan van de Ven wrote:
> > 
> > So it might be much better if we instead re-introduced that kind of "DMA 
> > latency requirement", and letting different subsystems react to that as 
> > they may.
> 
> wait.... we HAVE that infrastructure .. see kernel/latency.c ...

Heh. Just shows how wellknown that interface is - it seems like it's only 
used by the ipw2100 driver and "pcm_native".

But yes, that looks like the right thing.

> and the C-state code will honor it. CPUFREQ doesn't honor it yet but
> that's easy to add.. (this assumes the ACPI BIOS informs us correctly
> about the cpu behavior, but that's the best we can do obviously unless
> you want a table inside the kernel keyed off vendor/model/stepping)

Do we actually have the latency information for these things? Especially 
since I assume a number of people use the specialized direct-hw-access 
cpufreq drivers..

I realize that we *have* "transition_latency" at the cpufreq layer, and it 
is supposed to be in ns, but I wonder how likely it is to bear any 
relationship to reality, considering that I don't think it's really used 
for anything.. (yeah, it affects the heuristics, but I don't think it has 
any _hard_ meaning, so I'd worry that it's not necessarily something that 
people have tried to make accurate).

But I dunno.

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