linux-kernel - Re: [PATCH 0/6 v5.1] cfq-iosched: Introduce CFQ group hierarchical scheduling and "use

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]

Date:	Mon, 7 Mar 2011 09:28:28 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Gui Jianfeng <guijianfeng@...fujitsu.com>
Cc:	Jens Axboe <axboe@...nel.dk>,
	Justin TerAvest <teravest@...gle.com>,
	"jmoyer@...hat.com" <jmoyer@...hat.com>,
	Chad Talbott <ctalbott@...gle.com>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/6 v5.1] cfq-iosched: Introduce CFQ group hierarchical
 scheduling and "use_hierarchy" interface

On Sat, Mar 05, 2011 at 01:16:08PM +0800, Gui Jianfeng wrote:

[..]
> >> This bug seems being introduced in commmit 763414b in for-next branch when
> >> merging for-2.6.39/core branch.
> >> Would you apply the above patch?
> >>
> >> Vivek, can you try the patchset again with this fix? It works fine for me now.
> > 
> > Gui,
> > 
> > Ok, I ran iostest with this fix and it seems to have worked. I need to run
> > it for some more time. And I also need to spend more time reviewing your
> > patchset. There are so many details to it. Soon I will spare some time
> > to review it more and also test it bit more.
> 
> Vivek,
> 
> Ok, thanks.
> 
> > 
> > Of the top of my head I have one concern.
> > 
> > - How to map iopriority to weights. I am thinking that currently weight
> >   range is 100-1000. If we decide to extend the range in current scheme,
> >   it will change the ioprio entity weight also and effectively the
> >   service differentiation between ioprio level will change. I am
> >   wondering if this is a concern and how cpu scheduler has managed it
> 
> Isn't it enought for ten times of weight difference? The old ioprio scheme
> has only 4.5 times service difference. So I think we don't need to extend
> the range for the time being.

Well, never say never. I think google guys are already using minimum
weight of 10. So don't rule it out.

Secondly, because we might not idle all the time the effective service
differentiation might be much less than a factor of 10. In that case
to get effective 10, one might have to go for wider range of weights.

Thanks
Vivek
--
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/