Currently, the CKRM memory resource controller manages lists of pages per
class.
But pages referenced by two or more tasks attached to different classes
are
assigned whether to the class of the first user, whether to the class
which has the
max share value (done on task exit, for example). With this
implementation, the
pages of shared libraries or shell script text may migrate continuously
from one
class to another.
To handle pages shared between two or more CKRM classes, I tried a new
implementation that adds a new class in the memory controller to manage
these
pages. This class is named the "Shared" class.
The first time a page is referenced, it is added to the list of the class
the task
belongs to, as currently. When a page, already in the list of a class, but
not attached
to the Shared class, is referenced by a task that belongs to another
class, the page
is moved to the "Shared" class. Pages stay in the "Shared" list until they
are freed or
swapped out, they will never be moved to another class.
This "Shared" class is not configurable by user (no limit and no guarantee
attributes).
The "Shared" list is only shrinked when memory is running low. As there is
no limit
value for the Shared class, the list can grow as long as there is enough
free memory.
But this new class complicates accounting: a class has now pages in its
associated
list and a portion of pages attached to the "shared" class. Pages in the
Shared class
can also be shared between 2 or n classes. All simplifications and then
approximations I've done to calculate the portion of shared pages for a
class failed
to give satisfaction. So, I've done another implementation where the
shared pages
are not counted in the number of pages used by a class and not taken into
account
to manage the limit and guarantee of classes.
The memory controller manages many lists of pages (per-class and per-zone)
and
adding a new class complicates the balancing between the different lists:
when
reclaiming pages in the Shared class and how much?
Another way to manage shared pages is not to move them to a new class but
to the
default class which is always present and which has also no configurable
guarantee
and limit.The balancing between the lists does not change and that also
simplifies
the code.
I'm porting this code to the last version of the memory controller and
will post it here
soon. Some testing has been done on the previous version trying to
simulate different
workloads, but no benchmarking has been done yet.
Best regards,
Valérie
Dave Hansen <[EMAIL PROTECTED]>
08/12/2005 19:19
Pour : [EMAIL PROTECTED]
cc : [EMAIL PROTECTED], [email protected]
Objet : Re: Memory resource controller for f0.4 uploaded to project web
site
On Thu, 2005-12-08 at 17:52 +0100, [EMAIL PROTECTED] wrote:
> I'm working on some improvments to take into account feedbacks and
> comments that we had received. But, there are still some issues. I hope
> to propose them soon here.
Could you elaborate on what kinds of workloads are most effectively
controlled with the current memory controller design?
The thing that worries me the most about the controller is that it is
allocation-based. Whichever class forces the allocation is charged the
entire cost of keeping that page around. The reality is that many
classes could be utilizing a page, and the class _keeping_ a page in
memory has no guarantees about being the same that allocated it.
My favorite example is an apache server. The first class which receives
web requests will be likely be charged for bringing in apache's
executables and libraries. Many other classes may be served by that web
server, but only the first, unlucky, class pays the price for all of
these allocations. That seems pretty inherently unfair to me.
An alternative might be to charge classes for references to pages.
References are actually what cause memory pressure. Any page in the
system with no references to it is effectively free, and the class who
allocated it should not be charged the same cost as, say, an mlock()ed
page.
Now, this "references" approach isn't without its downsides. It has
implications as well. One class releasing its references could cause
the relative cost to another class to increase. This means that one
class's actions could cause another class to exceed its limits.
-- Dave
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
ckrm-tech mailing list
https://lists.sourceforge.net/lists/listinfo/ckrm-tech
