Re: [4/4] 2.6.23-rc3: known regressions

Linus Torvalds <[email protected]>
Newsgroups gmane.linux.usb.devel,gmane.linux.kernel
Message-ID <[email protected]>

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.