linux-kernel - Re: [RFC]cfq-iosched: quantum check tweak

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: <20100113111807.GC3087@redhat.com>
Date:	Wed, 13 Jan 2010 06:18:07 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Shaohua Li <shaohua.li@...el.com>
Cc:	Corrado Zoccolo <czoccolo@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"jens.axboe@...cle.com" <jens.axboe@...cle.com>,
	"Zhang, Yanmin" <yanmin.zhang@...el.com>
Subject: Re: [RFC]cfq-iosched: quantum check tweak

On Wed, Jan 13, 2010 at 04:17:35PM +0800, Shaohua Li wrote:
[..]
> > >  static bool cfq_may_dispatch(struct cfq_data *cfqd, struct cfq_queue *cfqq)
> > >  {
> > >  	unsigned int max_dispatch;
> > > @@ -2258,7 +2273,10 @@ static bool cfq_may_dispatch(struct cfq_
> > >  	if (cfqd->sync_flight && !cfq_cfqq_sync(cfqq))
> > >  		return false;
> > >  
> > > -	max_dispatch = cfqd->cfq_quantum;
> > > +	max_dispatch = cfqd->cfq_quantum / 2;
> > > +	if (max_dispatch < CFQ_SOFT_QUANTUM)
> > 
> > We don't have to hardcode CFQ_SOFT_QUANTUM or in fact we don't need it. We can
> > derive the soft limit from hard limit (cfq_quantum). Say soft limit will be
> > 50% of cfq_quantum value.
> I'm hoping this doesn't give user a surprise. Say cfq_quantum sets to 7, then we
> start doing throttling from 3 requests. Adding the CFQ_SOFT_QUANTUM gives a compatibility
> against old behavior at least. Am I over thinking?
>  

I would not worry too much about that. If you are really worried about
that, then create one Documentation/block/cfq-iosched.txt and document
how cfq_quantum works so that users know that cfq_quantum is upper hard
limit and internal soft limit is cfq_quantum/2.

Thanks
Vivek

> > > +		max_dispatch = min_t(unsigned int, CFQ_SOFT_QUANTUM,
> > > +			cfqd->cfq_quantum);
> > >  	if (cfq_class_idle(cfqq))
> > >  		max_dispatch = 1;
> > >  
> > > @@ -2275,7 +2293,7 @@ static bool cfq_may_dispatch(struct cfq_
> > >  		/*
> > >  		 * We have other queues, don't allow more IO from this one
> > >  		 */
> > > -		if (cfqd->busy_queues > 1)
> > > +		if (cfqd->busy_queues > 1 && cfq_slice_used_soon(cfqd, cfqq))
> > >  			return false;
> > 
> > So I guess here we can write something as follows.
> > 
> > 		if (cfqd->busy_queues > 1 && cfq_slice_used_soon(cfqd, cfqq))
> > 			return false;
> > 
> > 		if (cfqd->busy_queues == 1)
> > 			max_dispatch = -1;
> > 		else
> > 			/*
> > 			 * Normally we start throttling cfqq when cfq_quantum/2
> > 			 * requests have been dispatched. But we can drive
> > 			 * deeper queue depths at the beginning of slice
> > 			 * subjected to upper limit of cfq_quantum.
> > 			 */
> > 			max_dispatch = cfqd->cfq_quantum;
> ok.
> 
> Thanks,
> Shaohua
--
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/