linux-kernel - Re: [ProbableSpam] Re: [RFC, PATCH 0/5] Going forward with Resource Management

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:	Fri, 04 Aug 2006 13:02:59 -0400
From:	Shailabh Nagar <nagar@...son.ibm.com>
To:	Kirill Korotaev <dev@...ru>
CC:	vatsa@...ibm.com, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Andrew Morton <akpm@...l.org>, mingo@...e.hu,
	nickpiggin@...oo.com.au, sam@...ain.net,
	linux-kernel@...r.kernel.org, dev@...nvz.org, efault@....de,
	balbir@...ibm.com, sekharan@...ibm.com, haveblue@...ibm.com,
	pj@....com
Subject: Re: [ProbableSpam] Re: [RFC, PATCH 0/5] Going forward with Resource
 Management - A cpu  controller

Kirill Korotaev wrote:

>> The use cases I have heard of which would benefit such a feature is
>> (say) for database threads which want to change their "resource
>> affinity" status depending on which customer query they are currently
>> handling. If they are handling a query for a "important" customer,
>> they will want affinied
>> to a high bandwidth resource container and later if they start handling
>> a less important query they will want to give up this affinity and
>> instead move to a low-bandwidth container.
> 
> this works mostly for CPU only. 

And for block I/O bandwidth control since the priority of I/O requests can
also be changed dynamically pretty easily.


> And OpenVZ design allows to change CPU
> resource container  dynamically.
> 
> But such a trick works poorly for memory, because:
> 1. threads share lots of resources.
> 2. complex databases can have more complicated handling than a thread
> per request.
>  e.g. one thread servers memory pools, another one caches, some for
> stored procedures, some for requests etc.
> 

True. Stuff like memory, open files etc. are harder to control since
you can't take back allocations that easily and sharing with other tasks is
possible.

> BTW, exactly this difference shows the reason to have different groups
> for different resources.
> 

Good point.

> Thanks,
> Kirill
> 

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