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]
Date:	Thu, 05 Apr 2012 02:36:38 +0800
From:	Tao Ma <tm@....ma>
To:	Vivek Goyal <vgoyal@...hat.com>
CC:	Shaohua Li <shli@...nel.org>, Tejun Heo <tj@...nel.org>,
	axboe@...nel.dk, ctalbott@...gle.com, rni@...gle.com,
	linux-kernel@...r.kernel.org, cgroups@...r.kernel.org,
	containers@...ts.linux-foundation.org
Subject: Re: IOPS based scheduler (Was: Re: [PATCH 18/21] blkcg: move blkio_group_conf->weight
 to cfq)

On 04/05/2012 02:22 AM, Vivek Goyal wrote:
> On Thu, Apr 05, 2012 at 01:18:05AM +0800, Tao Ma wrote:
> 
> [..]
>>> I think a large chunk of that iops scheduler code will be borrowed from
>>> CFQ code. All the cgroup logic, queue creation logic, group scheduling
>>> logic etc. And that's the reason I was still exploring the possibility 
>>> of having common code base.
>> Yeah, actually I was thinking of abstracting a generic logic, but it
>> seems a lot bit hard. Maybe we can try to unify the code later?
> 
> I think if we change the cfqq scheduling logic to something similar to
> group scheduling logic, it will help a lot.
> 
> - Current virtual time based logic does not care whether you are operating
>   in time mode or iops mode. Switching cfqq logic to similar logic will
>   help moving to iops mode quickly.
> 
> - Keeping track of vtime will help that we will get rid of all the
>   residual time logic. If some queue was preempted, and did not use full
>   slice, we will automaticlally charge it less and give smaller vtime.
> 
> - Keeping both the scheduling logic will enable us the smoother
>   integration of both cfqq and group logic once we support hierarchical
>   cgroups.
> 
> - It will also enable easier integration of iops related logic.
Maybe, I will check all of these after my travel. Also I will try your
patch at that time.
> 
> So I am in favor of cleaning up CFQ code and change it to deal with both
> time as well iops. Seriously, implmenting time or iops is not hard. It is
> about rest of the logic like trees, groups which contributes towards bulk
> of the code and I am really not convinced that iops scheduler is going to
> be different enough that it needs new io scheduler.
Sure, I also want to make my problem perfect resolved while maitaining
things simple.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ