On Wed, Apr 16, 2014 at 03:33:06PM +0900, Hidetoshi Seto wrote: > I hope I can clarify my idea and thoughts in the following sentence... > > > [1] : should we make a change on a /proc/stat field semantic? > > As Frederic stated in previous mail: > <quote> > > So what we can do for example is to account it per task and update stats > > on the CPU where the blocking task wakes up. This way we guarantee > > that we only account locally, which is good for scalability. > > > > This is going to be an ABI change on a /proc/stat field semantic. > > We usually can not do that as it can break userspace. But I think > > we have a reasonable exception here: > > > > 1) On a performance POV we don't have the choice. > > > > 2) It has always been a buggy stat on SMP. Given the possible fast iowait > > update > > rate, I doubt it has ever dumped correct stats. So I guess that few user > > apps > > have ever correctly relied on it. > </quote> > > Basically I agree with this idea if we maintain only latest upstream in > development. But in case if target kernel is in family of stables or > some kind of distributor's kernel, I suppose this idea is not acceptable > because keeping semantics are very important for such environment. > > For example, you may propose that "hey, per-cpu iowait is completely > crap! so how about making this field in /proc/stat to stick to 0?" > It would be OK for latest upstream, as interim measure till new > iowait accounting mechanism is invented. But for stable kernels, > it will bring new regression report so it will not be any help. > > So we need 2 operations: > a) remove regression
What regression; there's never been talk about a regression, just a bug found. AFAICT this 'regression' is ever since we introduced NOHZ or somesuch, which is very long ago indeed. And since its basically been broken forever, there's no rush what so ever. > b) implement new iowait accounting mechanism > > What Frederic mentioned is that we don't need a) once if we invent > the solution for b). But I doubt it because a) is still required > for stable environment including some distributor's kernel. > It is clear that patches for b) will not be backportable. > > Still the b) is disease that has no known cure. There is no reason > to wait works on b) before starting works for a). As stated, there is no a). Its been forever broken. There is no urgency. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
