linux-kernel - RE: [RFC 0/1] Alternate history mechanism for the TEO governor

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] [day] [month] [year] [list]

Message-ID: <000901d632c2$cda7f8b0$68f7ea10$@net>
Date:   Mon, 25 May 2020 11:32:06 -0700
From:   "Doug Smythies" <dsmythies@...us.net>
To:     "'Pratik Sampat'" <psampat@...ux.ibm.com>
Cc:     <linux-kernel@...r.kernel.org>, <linux-pm@...r.kernel.org>,
        <rafael.j.wysocki@...el.com>, <peterz@...radead.org>,
        <daniel.lezcano@...aro.org>, <ego@...ux.vnet.ibm.com>,
        <svaidy@...ux.ibm.com>, <pratik.sampat@...ibm.com>,
        <pratik.r.sampat@...il.com>
Subject: RE: [RFC 0/1] Alternate history mechanism for the TEO governor

On 2020.05.21 04:09 Pratik Sampat wrote:
> On 17/05/20 11:41 pm, Doug Smythies wrote:
> > On 2020.05.11 Pratik Rajesh Sampat wrote:
> >> First RFC posting:https://lkml.org/lkml/2020/2/22/27
> > Summary:
> >
> > On that thread I wrote:
> >
> >    > I have done a couple of other tests with this patch set,
> >    > but nothing to report yet, as the differences have been
> >    > minor so far.
> >
> > I tried your tests, or as close as I could find, and still
> > do not notice much difference.
> 
> That is quite unfortunate. At least it doesn't seem to regress.

Yes, while I have not been able to demonstrate improvement,
I have not found any regression.

> 
> Nevertheless, as Rafael suggested aging is crucial, this patch doesn't age
> weights. I do have a version with aging but I had a lot of run to run variance
> so I had refrained from posting that.
> I'm tweaking around the logic for aging as well as distribution of weights,
> hopefully that may help.

O.K. I am putting this testing aside for now.
I like the set of tests, as they really show the differences between menu
and teo governors well.

> >>
> >> Sleeping Ebizzy
> >> ---------------
> >> Program to generate workloads resembling web server workloads.
> >> The benchmark is customized to allow for a sleep interval -i
> > I found a Phoronix ebizzy, but without the customization,
> > which I suspect is important to demonstrate your potential
> > improvement.
> >
> > Could you send me yours to try?
> 
> Sure thing, sleeping ebizzy is hosted here:
> https://github.com/pratiksampat/sleeping-ebizzy
> 
> >
> > ebizzy (records per second, more is better)
> >
> > teo		wtteo				menu
> > 132344	132228	99.91%	130926	98.93%

O.K. yours is way different than what I was using.
Anyway, results still are not very different
between teo and wtteo. Some tests are showing a little difference
between above/below statistics [1]

[1] http://www.smythies.com/~doug/linux/idle/wtteo/ebizzy-interval/2_below.png

By the way, and likely not relevant, your sleeping-ebizzy test
seems extremely sensitive to the interval and number of threads.
It is not clear to me what settings I should use to try to re-create
your results. [2] is an interesting graph of records per second verses
intervals verses threads.
 
[2] http://www.smythies.com/~doug/linux/idle/wtteo/doug08/sleeping-ebizzy-records-intervals-threads.png