On 01/18/2013 04:10 PM, Dave Chinner wrote:
> On Fri, Jan 18, 2013 at 11:10:00AM -0800, Glauber Costa wrote:
>> On 01/18/2013 12:11 AM, Dave Chinner wrote:
>>> On Thu, Jan 17, 2013 at 04:14:10PM -0800, Glauber Costa wrote:
On 01/17/2013 04:10 PM, Dave Chinner wrote:
> And then each object
On Fri, Jan 18, 2013 at 11:10:00AM -0800, Glauber Costa wrote:
> On 01/18/2013 12:11 AM, Dave Chinner wrote:
> > On Thu, Jan 17, 2013 at 04:14:10PM -0800, Glauber Costa wrote:
> >> On 01/17/2013 04:10 PM, Dave Chinner wrote:
> >>> And then each object uses:
> >>>
> >>> struct lru_item {
> >>>
On 01/18/2013 12:11 AM, Dave Chinner wrote:
> On Thu, Jan 17, 2013 at 04:14:10PM -0800, Glauber Costa wrote:
>> On 01/17/2013 04:10 PM, Dave Chinner wrote:
>>> And then each object uses:
>>>
>>> struct lru_item {
>>> struct list_head global_list;
>>> struct list_head memcg_list;
>>> }
>>
On 01/18/2013 12:08 AM, Dave Chinner wrote:
> On Thu, Jan 17, 2013 at 04:51:03PM -0800, Glauber Costa wrote:
>> On 01/17/2013 04:10 PM, Dave Chinner wrote:
>>> and we end up with:
>>>
>>> lru_add(struct lru_list *lru, struct lru_item *item)
>>> {
>>> node_id = min(object_to_nid(item),
On Thu, Jan 17, 2013 at 04:14:10PM -0800, Glauber Costa wrote:
> On 01/17/2013 04:10 PM, Dave Chinner wrote:
> > And then each object uses:
> >
> > struct lru_item {
> > struct list_head global_list;
> > struct list_head memcg_list;
> > }
> by objects you mean dentries, inodes, and the
On Thu, Jan 17, 2013 at 04:51:03PM -0800, Glauber Costa wrote:
> On 01/17/2013 04:10 PM, Dave Chinner wrote:
> > and we end up with:
> >
> > lru_add(struct lru_list *lru, struct lru_item *item)
> > {
> > node_id = min(object_to_nid(item), lru->numnodes);
> >
> > __lru_add(lru,
On Thu, Jan 17, 2013 at 04:51:03PM -0800, Glauber Costa wrote:
On 01/17/2013 04:10 PM, Dave Chinner wrote:
and we end up with:
lru_add(struct lru_list *lru, struct lru_item *item)
{
node_id = min(object_to_nid(item), lru-numnodes);
__lru_add(lru, node_id,
On Thu, Jan 17, 2013 at 04:14:10PM -0800, Glauber Costa wrote:
On 01/17/2013 04:10 PM, Dave Chinner wrote:
And then each object uses:
struct lru_item {
struct list_head global_list;
struct list_head memcg_list;
}
by objects you mean dentries, inodes, and the such, right?
On 01/18/2013 12:08 AM, Dave Chinner wrote:
On Thu, Jan 17, 2013 at 04:51:03PM -0800, Glauber Costa wrote:
On 01/17/2013 04:10 PM, Dave Chinner wrote:
and we end up with:
lru_add(struct lru_list *lru, struct lru_item *item)
{
node_id = min(object_to_nid(item), lru-numnodes);
On 01/18/2013 12:11 AM, Dave Chinner wrote:
On Thu, Jan 17, 2013 at 04:14:10PM -0800, Glauber Costa wrote:
On 01/17/2013 04:10 PM, Dave Chinner wrote:
And then each object uses:
struct lru_item {
struct list_head global_list;
struct list_head memcg_list;
}
by objects you mean
On Fri, Jan 18, 2013 at 11:10:00AM -0800, Glauber Costa wrote:
On 01/18/2013 12:11 AM, Dave Chinner wrote:
On Thu, Jan 17, 2013 at 04:14:10PM -0800, Glauber Costa wrote:
On 01/17/2013 04:10 PM, Dave Chinner wrote:
And then each object uses:
struct lru_item {
struct list_head
On 01/18/2013 04:10 PM, Dave Chinner wrote:
On Fri, Jan 18, 2013 at 11:10:00AM -0800, Glauber Costa wrote:
On 01/18/2013 12:11 AM, Dave Chinner wrote:
On Thu, Jan 17, 2013 at 04:14:10PM -0800, Glauber Costa wrote:
On 01/17/2013 04:10 PM, Dave Chinner wrote:
And then each object uses:
struct
On 01/17/2013 04:10 PM, Dave Chinner wrote:
> and we end up with:
>
> lru_add(struct lru_list *lru, struct lru_item *item)
> {
> node_id = min(object_to_nid(item), lru->numnodes);
>
> __lru_add(lru, node_id, >global_list);
> if (memcg) {
> memcg_lru =
On 01/17/2013 04:10 PM, Dave Chinner wrote:
> And then each object uses:
>
> struct lru_item {
> struct list_head global_list;
> struct list_head memcg_list;
> }
by objects you mean dentries, inodes, and the such, right?
Would it be acceptable to you?
We've been of course doing our
On Thu, Jan 17, 2013 at 10:21:12AM -0800, Glauber Costa wrote:
> >> Deepest fears:
> >>
> >> 1) snakes.
> >
> > Snakes are merely poisonous. Drop Bears are far more dangerous :P
>
> fears are irrational anyway...
>
> >> 2) It won't surprise you to know that I am adapting your work, which
> >>
>> Deepest fears:
>>
>> 1) snakes.
>
> Snakes are merely poisonous. Drop Bears are far more dangerous :P
>
fears are irrational anyway...
>> 2) It won't surprise you to know that I am adapting your work, which
>> provides a very sane and helpful API, to memcg shrinking.
>>
>> The dumb and
Deepest fears:
1) snakes.
Snakes are merely poisonous. Drop Bears are far more dangerous :P
fears are irrational anyway...
2) It won't surprise you to know that I am adapting your work, which
provides a very sane and helpful API, to memcg shrinking.
The dumb and simple approach in
On Thu, Jan 17, 2013 at 10:21:12AM -0800, Glauber Costa wrote:
Deepest fears:
1) snakes.
Snakes are merely poisonous. Drop Bears are far more dangerous :P
fears are irrational anyway...
2) It won't surprise you to know that I am adapting your work, which
provides a very sane
On 01/17/2013 04:10 PM, Dave Chinner wrote:
And then each object uses:
struct lru_item {
struct list_head global_list;
struct list_head memcg_list;
}
by objects you mean dentries, inodes, and the such, right?
Would it be acceptable to you?
We've been of course doing our best to
On 01/17/2013 04:10 PM, Dave Chinner wrote:
and we end up with:
lru_add(struct lru_list *lru, struct lru_item *item)
{
node_id = min(object_to_nid(item), lru-numnodes);
__lru_add(lru, node_id, item-global_list);
if (memcg) {
memcg_lru =
On Wed, Jan 16, 2013 at 04:35:43PM -0800, Glauber Costa wrote:
>
> >> The superblocks only, are present by the dozens even in a small system,
> >> and I believe the whole goal of this API is to get more users to switch
> >> to it. This can easily use up a respectable bunch of megs.
> >>
> >>
>> The superblocks only, are present by the dozens even in a small system,
>> and I believe the whole goal of this API is to get more users to switch
>> to it. This can easily use up a respectable bunch of megs.
>>
>> Isn't it a bit too much ?
>
> Maybe, but for active superblocks it only takes
On Wed, Jan 16, 2013 at 11:21:44AM -0800, Glauber Costa wrote:
> On 11/27/2012 03:14 PM, Dave Chinner wrote:
> > From: Dave Chinner
> >
> > Now that we have an LRU list API, we can start to enhance the
> > implementation. This splits the single LRU list into per-node lists
> > and locks to
On 11/27/2012 03:14 PM, Dave Chinner wrote:
> From: Dave Chinner
>
> Now that we have an LRU list API, we can start to enhance the
> implementation. This splits the single LRU list into per-node lists
> and locks to enhance scalability. Items are placed on lists
> according to the node the
On 11/27/2012 03:14 PM, Dave Chinner wrote:
From: Dave Chinner dchin...@redhat.com
Now that we have an LRU list API, we can start to enhance the
implementation. This splits the single LRU list into per-node lists
and locks to enhance scalability. Items are placed on lists
according to the
On Wed, Jan 16, 2013 at 11:21:44AM -0800, Glauber Costa wrote:
On 11/27/2012 03:14 PM, Dave Chinner wrote:
From: Dave Chinner dchin...@redhat.com
Now that we have an LRU list API, we can start to enhance the
implementation. This splits the single LRU list into per-node lists
and locks
The superblocks only, are present by the dozens even in a small system,
and I believe the whole goal of this API is to get more users to switch
to it. This can easily use up a respectable bunch of megs.
Isn't it a bit too much ?
Maybe, but for active superblocks it only takes a handful of
On Wed, Jan 16, 2013 at 04:35:43PM -0800, Glauber Costa wrote:
The superblocks only, are present by the dozens even in a small system,
and I believe the whole goal of this API is to get more users to switch
to it. This can easily use up a respectable bunch of megs.
Isn't it a bit too
On Thu, Dec 20, 2012 at 03:21:26PM +0400, Glauber Costa wrote:
> On 11/28/2012 03:14 AM, Dave Chinner wrote:
> > From: Dave Chinner
> >
> > Now that we have an LRU list API, we can start to enhance the
> > implementation. This splits the single LRU list into per-node lists
> > and locks to
On 11/28/2012 03:14 AM, Dave Chinner wrote:
> From: Dave Chinner
>
> Now that we have an LRU list API, we can start to enhance the
> implementation. This splits the single LRU list into per-node lists
> and locks to enhance scalability. Items are placed on lists
> according to the node the
On 11/28/2012 03:14 AM, Dave Chinner wrote:
From: Dave Chinner dchin...@redhat.com
Now that we have an LRU list API, we can start to enhance the
implementation. This splits the single LRU list into per-node lists
and locks to enhance scalability. Items are placed on lists
according to the
On Thu, Dec 20, 2012 at 03:21:26PM +0400, Glauber Costa wrote:
On 11/28/2012 03:14 AM, Dave Chinner wrote:
From: Dave Chinner dchin...@redhat.com
Now that we have an LRU list API, we can start to enhance the
implementation. This splits the single LRU list into per-node lists
and locks
From: Dave Chinner
Now that we have an LRU list API, we can start to enhance the
implementation. This splits the single LRU list into per-node lists
and locks to enhance scalability. Items are placed on lists
according to the node the memory belongs to. To make scanning the
lists efficient,
From: Dave Chinner dchin...@redhat.com
Now that we have an LRU list API, we can start to enhance the
implementation. This splits the single LRU list into per-node lists
and locks to enhance scalability. Items are placed on lists
according to the node the memory belongs to. To make scanning the
34 matches
Mail list logo
