diff for duplicates of <51ACFEBE.1050801@verisign.com> diff --git a/a/1.txt b/N1/1.txt index 2f6ad35..72caaad 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -5,8 +5,7 @@ I like Stratos' general idea of making the decision to upshift or downshift inde In my main use case (network servers), I don't think using more middle frequencies is a good thing at all; as soon as a load gets heavy even briefly I want the CPU doing all it can until the load has clearly abated. The main competition in this use case is between using ondemand (tuned for performance at the cost of some extra power consumption) or the "performance" governor (which cannot be tuned at all, and where C-states are the only hope for moderating power consumption). -A couple of additional points -- it is possible to get excellent overall performance and avoid oscillation using ondemand right now by using a low up_threshold and a sampling_down_factor of around 100; in this case you spend most of your time at either the lowest or highest possible frequency and you spend very little time thinking about slowing down. The main downside of this is an increase in power consumption, so it is not a battery-friendly approach, but someone will need to also measure power consumption if we want to justify a change from the status quo on that basis. There are dozens of ways to save power at the expense of performance or vice versa, so any major change like this needs to be analyzed for both, in case your patch just results in running at higher average frequencies - and gets its performance boost from that. +A couple of additional points -- it is possible to get excellent overall performance and avoid oscillation using ondemand right now by using a low up_threshold and a sampling_down_factor of around 100; in this case you spend most of your time at either the lowest or highest possible frequency and you spend very little time thinking about slowing down. The main downside of this is an increase in power consumption, so it is not a battery-friendly approach, but someone will need to also measure power consumption if we want to justify a change from the status quo on that basis. There are dozens of ways to save power at the expense of performance or vice versa, so any major change like this needs to be analyzed for both, in case your patch just results in running at higher average frequencies and gets its performance boost from that. David C Niemi diff --git a/a/content_digest b/N1/content_digest index db5ee49..1865595 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -20,8 +20,7 @@ "\n" "In my main use case (network servers), I don't think using more middle frequencies is a good thing at all; as soon as a load gets heavy even briefly I want the CPU doing all it can until the load has clearly abated. The main competition in this use case is between using ondemand (tuned for performance at the cost of some extra power consumption) or the \"performance\" governor (which cannot be tuned at all, and where C-states are the only hope for moderating power consumption).\n" "\n" - "A couple of additional points -- it is possible to get excellent overall performance and avoid oscillation using ondemand right now by using a low up_threshold and a sampling_down_factor of around 100; in this case you spend most of your time at either the lowest or highest possible frequency and you spend very little time thinking about slowing down. The main downside of this is an increase in power consumption, so it is not a battery-friendly approach, but someone will need to also measure power consumption if we want to justify a change from the status quo on that basis. There are dozens of ways to save power at the expense of performance or vice versa, so any major change like this needs to be analyzed for both, in case your patch just results in running at higher average frequencies\n" - " and gets its performance boost from that.\n" + "A couple of additional points -- it is possible to get excellent overall performance and avoid oscillation using ondemand right now by using a low up_threshold and a sampling_down_factor of around 100; in this case you spend most of your time at either the lowest or highest possible frequency and you spend very little time thinking about slowing down. The main downside of this is an increase in power consumption, so it is not a battery-friendly approach, but someone will need to also measure power consumption if we want to justify a change from the status quo on that basis. There are dozens of ways to save power at the expense of performance or vice versa, so any major change like this needs to be analyzed for both, in case your patch just results in running at higher average frequencies and gets its performance boost from that.\n" "\n" "David C Niemi\n" "\n" @@ -60,4 +59,4 @@ ">\n" ... -da1dee4322436aa3d5f090db6f976c44a8800c7f03f8f63f8fd676ed29c6f8cd +569b33faf7b4a253a6112f85f1c1e515bcdda88c697ac115173bced62f2bc58c
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.