On Mon, 2016-04-11 at 05:04 +0200, Mike Galbraith wrote: > On Sun, 2016-04-10 at 16:24 -0400, Rik van Riel wrote: > > > > On Sun, 2016-04-10 at 17:39 +0200, Mike Galbraith wrote: > > > > > > > > Should the default idle state not then be governor > > > dependent? When I > > > set gov=performance, I'm expecting box to go just as fast as it > > > can > > > go > > > without melting. Does polling risk CPU -> lava conversion? > > Current CPUs can only have some cores run at full speed > > (turbo mode) if other cores are idling and/or running at > > lower speeds. > The real world is very unlikely to miss the prettier numbers I'm > grieving over one tiny bit. Knowing that doesn't make giving them up > any easier though.. byebye cycles (sniff) ;-)
I suspect your pipe benchmark could be very relevant to network performance numbers, too. I would like to go into polling a little bit more aggressively in a future kernel, and I think we can get away with it if we teach the polling loop to exit after we have spent enough time there that the menu governor will pick HLT after a few timed out poll loops. That way while we run a workload that actually benefits from polling, we will get polling, but once we run a workload that actually sleeps longer than the HLT threshold, we will quickly fall back to HLT. With 10Gbps network traffic, it could make a real difference whether or not the CPU can wake up immediately, or takes a microsecond to wake up... -- All Rights Reversed.
signature.asc
Description: This is a digitally signed message part