linux-kernel - Re: [PATCH] CFQ: Don't store left slice when slice used up or for a idle workload

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: <x49aapuci3n.fsf@segfault.boston.devel.redhat.com>
Date:	Wed, 14 Jul 2010 09:23:40 -0400
From:	Jeff Moyer <jmoyer@...hat.com>
To:	Gui Jianfeng <guijianfeng@...fujitsu.com>
Cc:	Jens Axboe <axboe@...nel.dk>, Vivek Goyal <vgoyal@...hat.com>,
	Corrado Zoccolo <czoccolo@...il.com>,
	linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] CFQ: Don't store left slice when slice used up or for a idle workload

Gui Jianfeng <guijianfeng@...fujitsu.com> writes:

> Jeff Moyer wrote:
>> Gui Jianfeng <guijianfeng@...fujitsu.com> writes:
>> 
>>> It doesn't make sence to store left time slice for an idle workload
>>> or for the cfqq that uses up its slice.
>> 
>> Did you actually observe any problems?  As I understand it, if you
>> overrun your slice you get a negative offset, so I think we want to keep
>> that.
>
> Hi Jeff
>
> If that's the case, do we also need to store the negative offset when slice
> used up in cfq_select_queue() and cfq_idle_slice_timer()?

Good question;  the code is inconsistent as it stands.

        /*
         * store what was left of this slice, if the queue idled/timed out
         */

If we are to believe that comment, then yes, we should also call
cfq_slice_expired with timed_out set to 1 in cfq_idle_slice_timer when
the slice is used, and for certain cases in select_queue.

I find this counter-intuitive, actually.  I would have stored residual
for quite the opposite situation: where you are preempted and so don't
get to run for your fair share.  But, there must be some
logic/experience behind the current mechanism....

Cheers,
Jeff
--
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/