All of lore.kernel.org
 help / color / mirror / Atom feed
From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: Paul Menage <menage@google.com>
Cc: Linux Containers <containers@lists.osdl.org>,
	Linux MM Mailing List <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	David Rientjes <rientjes@google.com>
Subject: Re: [-mm PATCH] Memory controller improve user interface
Date: Wed, 29 Aug 2007 21:37:38 +0530	[thread overview]
Message-ID: <46D599CA.1020504@linux.vnet.ibm.com> (raw)
In-Reply-To: <6599ad830708290828t5164260eid548757d404e31a5@mail.gmail.com>

Paul Menage wrote:
> On 8/29/07, Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
>> Change the interface to use kilobytes instead of pages. Page sizes can vary
>> across platforms and configurations. A new strategy routine has been added
>> to the resource counters infrastructure to format the data as desired.
>>
>> Suggested by David Rientjes, Andrew Morton and Herbert Poetzl
>>
>> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
>> ---
>>
>>  Documentation/controllers/memory.txt |    7 +++--
>>  include/linux/res_counter.h          |    6 ++--
>>  kernel/res_counter.c                 |   24 +++++++++++++----
>>  mm/memcontrol.c                      |   47 +++++++++++++++++++++++++++--------
>>  4 files changed, 64 insertions(+), 20 deletions(-)
>>
>> diff -puN mm/memcontrol.c~mem-control-make-ui-use-kilobytes mm/memcontrol.c
>> --- linux-2.6.23-rc3/mm/memcontrol.c~mem-control-make-ui-use-kilobytes  2007-08-28 13:20:44.000000000 +0530
>> +++ linux-2.6.23-rc3-balbir/mm/memcontrol.c     2007-08-29 14:36:07.000000000 +0530
>> @@ -32,6 +32,7 @@
>>
>>  struct container_subsys mem_container_subsys;
>>  static const int MEM_CONTAINER_RECLAIM_RETRIES = 5;
>> +static const int MEM_CONTAINER_CHARGE_KB = (PAGE_SIZE >> 10);
>>
>>  /*
>>   * The memory controller data structure. The memory controller controls both
>> @@ -312,7 +313,7 @@ int mem_container_charge(struct page *pa
>>          * If we created the page_container, we should free it on exceeding
>>          * the container limit.
>>          */
>> -       while (res_counter_charge(&mem->res, 1)) {
>> +       while (res_counter_charge(&mem->res, MEM_CONTAINER_CHARGE_KB)) {
>>                 if (try_to_free_mem_container_pages(mem))
>>                         continue;
>>
>> @@ -352,7 +353,7 @@ int mem_container_charge(struct page *pa
>>                 kfree(pc);
>>                 pc = race_pc;
>>                 atomic_inc(&pc->ref_cnt);
>> -               res_counter_uncharge(&mem->res, 1);
>> +               res_counter_uncharge(&mem->res, MEM_CONTAINER_CHARGE_KB);
>>                 css_put(&mem->css);
>>                 goto done;
>>         }
>> @@ -417,7 +418,7 @@ void mem_container_uncharge(struct page_
>>                 css_put(&mem->css);
>>                 page_assign_page_container(page, NULL);
>>                 unlock_page_container(page);
>> -               res_counter_uncharge(&mem->res, 1);
>> +               res_counter_uncharge(&mem->res, MEM_CONTAINER_CHARGE_KB);
>>
>>                 spin_lock_irqsave(&mem->lru_lock, flags);
>>                 list_del_init(&pc->lru);
>> @@ -426,12 +427,37 @@ void mem_container_uncharge(struct page_
>>         }
>>  }
>>
>> -static ssize_t mem_container_read(struct container *cont, struct cftype *cft,
>> -                       struct file *file, char __user *userbuf, size_t nbytes,
>> -                       loff_t *ppos)
>> +int mem_container_read_strategy(unsigned long val, char *buf)
>> +{
>> +       return sprintf(buf, "%lu (kB)\n", val);
>> +}
>> +
>> +int mem_container_write_strategy(char *buf, unsigned long *tmp)
>> +{
>> +       *tmp = memparse(buf, &buf);
>> +       if (*buf != '\0')
>> +               return -EINVAL;
>> +
>> +       *tmp = *tmp >> 10;              /* convert to kilobytes */
>> +       return 0;
>> +}
> 
> This seems a bit inconsistent - if you write a value to a limit file,
> then the value that you read back is reduced by a factor of 1024?
> Having the "(kB)" suffix isn't really a big help to automated
> middleware.
> 

Why is that? Is it because you could write 4M and see it show up
as 4096 kilobytes? We'll that can be fixed with another variant
of the memparse() utility.

> I'd still be in favour of just reading/writing 64-bit values
> representing bytes - simple, and unambiguous for programmatic use, and
> not really any less user-friendly than kilobytes  for manual use
> (since the numbers involved are going to be unwieldly for manual use
> whether they're in bytes or kB).
> 

64 bit might be an overkill for 32 bit machines. 32 bit machines with
PAE cannot use 32 bit values, they need 64 bits. I think KiloBytes
is an acceptable metric these days, everybody understands them.

> Paul
> _______________________________________________
> Containers mailing list
> Containers@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/containers


-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL

WARNING: multiple messages have this Message-ID (diff)
From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: Paul Menage <menage@google.com>
Cc: Linux Containers <containers@lists.osdl.org>,
	Linux MM Mailing List <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	David Rientjes <rientjes@google.com>
Subject: Re: [-mm PATCH] Memory controller improve user interface
Date: Wed, 29 Aug 2007 21:37:38 +0530	[thread overview]
Message-ID: <46D599CA.1020504@linux.vnet.ibm.com> (raw)
In-Reply-To: <6599ad830708290828t5164260eid548757d404e31a5@mail.gmail.com>

Paul Menage wrote:
> On 8/29/07, Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
>> Change the interface to use kilobytes instead of pages. Page sizes can vary
>> across platforms and configurations. A new strategy routine has been added
>> to the resource counters infrastructure to format the data as desired.
>>
>> Suggested by David Rientjes, Andrew Morton and Herbert Poetzl
>>
>> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
>> ---
>>
>>  Documentation/controllers/memory.txt |    7 +++--
>>  include/linux/res_counter.h          |    6 ++--
>>  kernel/res_counter.c                 |   24 +++++++++++++----
>>  mm/memcontrol.c                      |   47 +++++++++++++++++++++++++++--------
>>  4 files changed, 64 insertions(+), 20 deletions(-)
>>
>> diff -puN mm/memcontrol.c~mem-control-make-ui-use-kilobytes mm/memcontrol.c
>> --- linux-2.6.23-rc3/mm/memcontrol.c~mem-control-make-ui-use-kilobytes  2007-08-28 13:20:44.000000000 +0530
>> +++ linux-2.6.23-rc3-balbir/mm/memcontrol.c     2007-08-29 14:36:07.000000000 +0530
>> @@ -32,6 +32,7 @@
>>
>>  struct container_subsys mem_container_subsys;
>>  static const int MEM_CONTAINER_RECLAIM_RETRIES = 5;
>> +static const int MEM_CONTAINER_CHARGE_KB = (PAGE_SIZE >> 10);
>>
>>  /*
>>   * The memory controller data structure. The memory controller controls both
>> @@ -312,7 +313,7 @@ int mem_container_charge(struct page *pa
>>          * If we created the page_container, we should free it on exceeding
>>          * the container limit.
>>          */
>> -       while (res_counter_charge(&mem->res, 1)) {
>> +       while (res_counter_charge(&mem->res, MEM_CONTAINER_CHARGE_KB)) {
>>                 if (try_to_free_mem_container_pages(mem))
>>                         continue;
>>
>> @@ -352,7 +353,7 @@ int mem_container_charge(struct page *pa
>>                 kfree(pc);
>>                 pc = race_pc;
>>                 atomic_inc(&pc->ref_cnt);
>> -               res_counter_uncharge(&mem->res, 1);
>> +               res_counter_uncharge(&mem->res, MEM_CONTAINER_CHARGE_KB);
>>                 css_put(&mem->css);
>>                 goto done;
>>         }
>> @@ -417,7 +418,7 @@ void mem_container_uncharge(struct page_
>>                 css_put(&mem->css);
>>                 page_assign_page_container(page, NULL);
>>                 unlock_page_container(page);
>> -               res_counter_uncharge(&mem->res, 1);
>> +               res_counter_uncharge(&mem->res, MEM_CONTAINER_CHARGE_KB);
>>
>>                 spin_lock_irqsave(&mem->lru_lock, flags);
>>                 list_del_init(&pc->lru);
>> @@ -426,12 +427,37 @@ void mem_container_uncharge(struct page_
>>         }
>>  }
>>
>> -static ssize_t mem_container_read(struct container *cont, struct cftype *cft,
>> -                       struct file *file, char __user *userbuf, size_t nbytes,
>> -                       loff_t *ppos)
>> +int mem_container_read_strategy(unsigned long val, char *buf)
>> +{
>> +       return sprintf(buf, "%lu (kB)\n", val);
>> +}
>> +
>> +int mem_container_write_strategy(char *buf, unsigned long *tmp)
>> +{
>> +       *tmp = memparse(buf, &buf);
>> +       if (*buf != '\0')
>> +               return -EINVAL;
>> +
>> +       *tmp = *tmp >> 10;              /* convert to kilobytes */
>> +       return 0;
>> +}
> 
> This seems a bit inconsistent - if you write a value to a limit file,
> then the value that you read back is reduced by a factor of 1024?
> Having the "(kB)" suffix isn't really a big help to automated
> middleware.
> 

Why is that? Is it because you could write 4M and see it show up
as 4096 kilobytes? We'll that can be fixed with another variant
of the memparse() utility.

> I'd still be in favour of just reading/writing 64-bit values
> representing bytes - simple, and unambiguous for programmatic use, and
> not really any less user-friendly than kilobytes  for manual use
> (since the numbers involved are going to be unwieldly for manual use
> whether they're in bytes or kB).
> 

64 bit might be an overkill for 32 bit machines. 32 bit machines with
PAE cannot use 32 bit values, they need 64 bits. I think KiloBytes
is an acceptable metric these days, everybody understands them.

> Paul
> _______________________________________________
> Containers mailing list
> Containers@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/containers


-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2007-08-29 16:07 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-29 11:10 [-mm PATCH] Memory controller improve user interface Balbir Singh
2007-08-29 11:10 ` Balbir Singh
2007-08-29 15:28 ` Paul Menage
2007-08-29 15:28   ` Paul Menage
2007-08-29 16:07   ` Balbir Singh [this message]
2007-08-29 16:07     ` Balbir Singh
2007-08-29 16:17     ` Paul Menage
2007-08-29 16:17       ` Paul Menage
2007-08-29 18:45 ` Dave Hansen
2007-08-29 18:45   ` Dave Hansen
2007-08-29 22:04   ` Balbir Singh
2007-08-29 22:04     ` Balbir Singh
2007-08-29 22:04     ` Balbir Singh
2007-08-29 22:18     ` Dave Hansen
2007-08-29 22:18       ` Dave Hansen
2007-08-29 22:20       ` Paul Menage
2007-08-29 22:20         ` Paul Menage
2007-08-29 22:25         ` Dave Hansen
2007-08-29 22:25           ` Dave Hansen
2007-08-29 22:37           ` Balbir Singh
2007-08-29 22:37             ` Balbir Singh
2007-08-29 22:37             ` Balbir Singh
2007-08-30  5:38             ` KAMEZAWA Hiroyuki
2007-08-30  5:38               ` KAMEZAWA Hiroyuki
     [not found]               ` <20070830143859.e9d3511a.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2007-08-30  9:13                 ` Balbir Singh
2007-08-30  9:13                   ` Balbir Singh
2007-08-30  9:13                   ` Balbir Singh
2007-08-29 22:27       ` Balbir Singh
2007-08-29 22:27         ` Balbir Singh
2007-08-29 22:36         ` Dave Hansen
2007-08-29 22:36           ` Dave Hansen
2007-08-29 22:44           ` Balbir Singh
2007-08-29 22:44             ` Balbir Singh
2007-08-29 22:44             ` Balbir Singh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46D599CA.1020504@linux.vnet.ibm.com \
    --to=balbir@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=containers@lists.osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=menage@google.com \
    --cc=rientjes@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.