linux-kernel - Re: [PATCH 0/2 v4] sched: Rewrite per entity runnable load average tracking

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: <20140731021532.GE28673@intel.com>
Date:	Thu, 31 Jul 2014 10:15:33 +0800
From:	Yuyang Du <yuyang.du@...el.com>
To:	Morten Rasmussen <morten.rasmussen@....com>
Cc:	"mingo@...hat.com" <mingo@...hat.com>,
	"peterz@...radead.org" <peterz@...radead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"pjt@...gle.com" <pjt@...gle.com>,
	"bsegall@...gle.com" <bsegall@...gle.com>,
	"arjan.van.de.ven@...el.com" <arjan.van.de.ven@...el.com>,
	"len.brown@...el.com" <len.brown@...el.com>,
	"rafael.j.wysocki@...el.com" <rafael.j.wysocki@...el.com>,
	"alan.cox@...el.com" <alan.cox@...el.com>,
	"mark.gross@...el.com" <mark.gross@...el.com>,
	"fengguang.wu@...el.com" <fengguang.wu@...el.com>
Subject: Re: [PATCH 0/2 v4] sched: Rewrite per entity runnable load average
 tracking

On Thu, Jul 31, 2014 at 09:54:21AM +0100, Morten Rasmussen wrote:
> 
> Overall, it is not clear to me why it is necessary to rewrite the
> per-entity load-tracking. The code is somewhat simpler, but I don't see
> any functional additions/improvements. If we have to go through a long
> review and testing process, why not address some of the most obvious
> issues with the existing implementation while we are at it? I don't see
> the point in replacing something sub-optimal with equally sub-optimal
> (or worse).
> 

This is absolutely nonsense. First, we have improvements, second, even
with no functions addition, but do you really understand what has been
changed besides simpler. Even just simpler, simpler means a lot of things..

> > I do think there absolutely can be sub-optimal cases.

I said there absolutely can be sub-optimal cases, which exactly referred to
the example you gave (one 10% 88761 vs. 8 100% 1024). Still, the links
does not say anything about how serious. Exist, yes, serious, don't know.

> > But as I said, I just don't think the problem description is clear enough.

I said your description is not clear enough, and at the time I was not
clear either. Arguably and sadly, none of what you said in this response
made a tiny little progress. About blocked load, prediction, ..., can you
be more wrong?

The problem is not weight scaling. The problem is how weight is accumulated
when not runnable. Why? Consider this, if all tasks are always runnalbe,
weight scaling cann't be more right.

WRT runnalbe weight, currently, it is runnalbe% * weight (simplified).
Since weight has so big range, it dwarfs runnable time ratio. So maybe what
can be done is (what I have in mind):

1) runnalbe%^2 * weight
2) bigger weight does faster decay

Still, if you can prove the issue is serious, we can try something..., but just
nothing is perfect.

Thanks,
Yuyang
--
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/