Re: [PATCH 0/2] Make core_pattern support namespace

On 2016/03/16 18:23, Zhao Lei wrote: > We discussed patch titled: > [PATCH] Make core_pattern support namespace > before. > > Above patch can solve half problem of custom core_dump pattern > in container, but there are also another problem that limit > custom core_pattern in container, it is

Re: [PATCH 0/2] Make core_pattern support namespace

On 2016/03/16 18:23, Zhao Lei wrote: > We discussed patch titled: > [PATCH] Make core_pattern support namespace > before. > > Above patch can solve half problem of custom core_dump pattern > in container, but there are also another problem that limit > custom core_pattern in container, it is

Re: call_usermodehelper in containers

On 2016/02/19 14:37, Ian Kent wrote: On Fri, 2016-02-19 at 12:08 +0900, Kamezawa Hiroyuki wrote: On 2016/02/19 5:45, Eric W. Biederman wrote: Personally I am a fan of the don't be clever and capture a kernel thread approach as it is very easy to see you what if any exploitation opportunities

Re: call_usermodehelper in containers

On 2016/02/19 14:37, Ian Kent wrote: On Fri, 2016-02-19 at 12:08 +0900, Kamezawa Hiroyuki wrote: On 2016/02/19 5:45, Eric W. Biederman wrote: Personally I am a fan of the don't be clever and capture a kernel thread approach as it is very easy to see you what if any exploitation opportunities

Re: call_usermodehelper in containers

On 2016/02/19 5:45, Eric W. Biederman wrote: > Personally I am a fan of the don't be clever and capture a kernel thread > approach as it is very easy to see you what if any exploitation > opportunities there are. The justifications for something more clever > is trickier. Of course we do

Re: call_usermodehelper in containers

On 2016/02/19 5:45, Eric W. Biederman wrote: > Personally I am a fan of the don't be clever and capture a kernel thread > approach as it is very easy to see you what if any exploitation > opportunities there are. The justifications for something more clever > is trickier. Of course we do

Re: call_usermodehelper in containers

On 2016/02/18 11:57, Eric W. Biederman wrote: > > Ccing The containers list because a related discussion is happening there > and somehow this thread has never made it there. > > Ian Kent writes: > >> On Mon, 2013-11-18 at 18:28 +0100, Oleg Nesterov wrote: >>> On 11/15, Eric

Re: call_usermodehelper in containers

On 2016/02/18 11:57, Eric W. Biederman wrote: > > Ccing The containers list because a related discussion is happening there > and somehow this thread has never made it there. > > Ian Kent writes: > >> On Mon, 2013-11-18 at 18:28 +0100, Oleg Nesterov wrote: >>> On 11/15, Eric W. Biederman

Re: [Propose] Isolate core_pattern in mnt namespace.

On 2015/12/22 6:52, Eric W. Biederman wrote: > Dongsheng Yang writes: > >> On 12/20/2015 05:47 PM, Eric W. Biederman wrote: >>> Dongsheng Yang writes: >>> On 12/20/2015 10:37 AM, Al Viro wrote: > On Sun, Dec 20, 2015 at 10:14:29AM +0800, Dongsheng Yang wrote: >> On 12/17/2015 07:23

Re: [Propose] Isolate core_pattern in mnt namespace.

On 2015/12/22 6:52, Eric W. Biederman wrote: > Dongsheng Yang writes: > >> On 12/20/2015 05:47 PM, Eric W. Biederman wrote: >>> Dongsheng Yang writes: >>> On 12/20/2015 10:37 AM, Al Viro wrote: > On Sun, Dec 20, 2015 at 10:14:29AM

Re: [Propose] Isolate core_pattern in mnt namespace.

On 2015/12/20 18:47, Eric W. Biederman wrote: > Dongsheng Yang writes: > >> On 12/20/2015 10:37 AM, Al Viro wrote: >>> On Sun, Dec 20, 2015 at 10:14:29AM +0800, Dongsheng Yang wrote: On 12/17/2015 07:23 PM, Dongsheng Yang wrote: > Hi guys, > We are working on making core dump

Re: [Propose] Isolate core_pattern in mnt namespace.

On 2015/12/20 18:47, Eric W. Biederman wrote: > Dongsheng Yang writes: > >> On 12/20/2015 10:37 AM, Al Viro wrote: >>> On Sun, Dec 20, 2015 at 10:14:29AM +0800, Dongsheng Yang wrote: On 12/17/2015 07:23 PM, Dongsheng Yang wrote: > Hi guys, > We are

Re: [PATCH v2 7/7] Documentation: cgroup: add memory.swap.{current,max} description

On 2015/12/17 21:30, Vladimir Davydov wrote: > The rationale of separate swap counter is given by Johannes Weiner. > > Signed-off-by: Vladimir Davydov > --- > Changes in v2: > - Add rationale of separate swap counter provided by Johannes. > > Documentation/cgroup.txt | 33

Re: [PATCH v3 2/2] mm: Introduce kernelcore=mirror option

On 2015/12/18 3:43, Luck, Tony wrote: As Tony requested, we may need a knob to stop a fallback in "movable->normal", later. If the mirrored memory is small and the other is large, I think we can both enable "non-mirrored -> normal" and "normal -> non-mirrored". Size of mirrored memory can

Re: [PATCH v3 2/2] mm: Introduce kernelcore=mirror option

On 2015/12/18 3:43, Luck, Tony wrote: As Tony requested, we may need a knob to stop a fallback in "movable->normal", later. If the mirrored memory is small and the other is large, I think we can both enable "non-mirrored -> normal" and "normal -> non-mirrored". Size of mirrored memory can

Re: [PATCH v2 7/7] Documentation: cgroup: add memory.swap.{current,max} description

On 2015/12/17 21:30, Vladimir Davydov wrote: > The rationale of separate swap counter is given by Johannes Weiner. > > Signed-off-by: Vladimir Davydov > --- > Changes in v2: > - Add rationale of separate swap counter provided by Johannes. > > Documentation/cgroup.txt

Re: [PATCH v3 2/2] mm: Introduce kernelcore=mirror option

On 2015/12/17 13:48, Xishi Qiu wrote: > On 2015/12/17 10:53, Kamezawa Hiroyuki wrote: > >> On 2015/12/17 11:47, Xishi Qiu wrote: >>> On 2015/12/17 9:38, Izumi, Taku wrote: >>> >>>> Dear Xishi, >>>> >>>>Sorry for late. >>

Re: [PATCH 1/7] mm: memcontrol: charge swap to cgroup2

On 2015/12/17 12:32, Johannes Weiner wrote: On Thu, Dec 17, 2015 at 11:46:27AM +0900, Kamezawa Hiroyuki wrote: On 2015/12/16 20:09, Johannes Weiner wrote: On Wed, Dec 16, 2015 at 12:18:30PM +0900, Kamezawa Hiroyuki wrote: - swap-full notification via vmpressure or something mechanism. Why

Re: [PATCH v3 2/2] mm: Introduce kernelcore=mirror option

6:44 PM >>> To: Izumi, Taku/泉 拓 >>> Cc: Luck, Tony; linux-kernel@vger.kernel.org; linux...@kvack.org; >>> a...@linux-foundation.org; Kamezawa, Hiroyuki/亀澤 寛 >>> 之; m...@csn.ul.ie; Hansen, Dave; m...@codeblueprint.co.uk >>> Subject: Re: [PATCH v3 2/2] mm:

Re: [PATCH 1/7] mm: memcontrol: charge swap to cgroup2

On 2015/12/16 20:09, Johannes Weiner wrote: On Wed, Dec 16, 2015 at 12:18:30PM +0900, Kamezawa Hiroyuki wrote: Hmm, my requests are - set the same capabilities as mlock() to set swap.limit=0 Setting swap.max is already privileged operation. Sure. - swap-full notification via

Re: [PATCH 1/7] mm: memcontrol: charge swap to cgroup2

On 2015/12/17 12:32, Johannes Weiner wrote: On Thu, Dec 17, 2015 at 11:46:27AM +0900, Kamezawa Hiroyuki wrote: On 2015/12/16 20:09, Johannes Weiner wrote: On Wed, Dec 16, 2015 at 12:18:30PM +0900, Kamezawa Hiroyuki wrote: - swap-full notification via vmpressure or something mechanism. Why

Re: [PATCH v3 2/2] mm: Introduce kernelcore=mirror option

On 2015/12/17 13:48, Xishi Qiu wrote: > On 2015/12/17 10:53, Kamezawa Hiroyuki wrote: > >> On 2015/12/17 11:47, Xishi Qiu wrote: >>> On 2015/12/17 9:38, Izumi, Taku wrote: >>> >>>> Dear Xishi, >>>> >>>>Sorry for late. >>

Re: [PATCH 1/7] mm: memcontrol: charge swap to cgroup2

On 2015/12/16 20:09, Johannes Weiner wrote: On Wed, Dec 16, 2015 at 12:18:30PM +0900, Kamezawa Hiroyuki wrote: Hmm, my requests are - set the same capabilities as mlock() to set swap.limit=0 Setting swap.max is already privileged operation. Sure. - swap-full notification via

Re: [PATCH v3 2/2] mm: Introduce kernelcore=mirror option

6:44 PM >>> To: Izumi, Taku/泉 拓 >>> Cc: Luck, Tony; linux-kernel@vger.kernel.org; linux...@kvack.org; >>> a...@linux-foundation.org; Kamezawa, Hiroyuki/亀澤 寛 >>> 之; m...@csn.ul.ie; Hansen, Dave; m...@codeblueprint.co.uk >>> Subject: Re: [PATCH v3 2/2] mm:

Re: [PATCH 1/7] mm: memcontrol: charge swap to cgroup2

On 2015/12/16 2:21, Michal Hocko wrote: I completely agree that malicious/untrusted users absolutely have to be capped by the hard limit. Then the separate swap limit would work for sure. But I am less convinced about usefulness of the rigid (to the global memory pressure) swap limit without

Re: [PATCH 1/7] mm: memcontrol: charge swap to cgroup2

On 2015/12/15 23:50, Johannes Weiner wrote: On Tue, Dec 15, 2015 at 12:22:41PM +0900, Kamezawa Hiroyuki wrote: On 2015/12/15 4:42, Vladimir Davydov wrote: Anyway, if you don't trust a container you'd better set the hard memory limit so that it can't hurt others no matter what it runs and how

Re: [PATCH 1/7] mm: memcontrol: charge swap to cgroup2

On 2015/12/15 20:02, Vladimir Davydov wrote: On Tue, Dec 15, 2015 at 12:22:41PM +0900, Kamezawa Hiroyuki wrote: On 2015/12/15 4:42, Vladimir Davydov wrote: On Mon, Dec 14, 2015 at 04:30:37PM +0100, Michal Hocko wrote: On Thu 10-12-15 14:39:14, Vladimir Davydov wrote: In the legacy hierarchy

Re: [PATCH 1/7] mm: memcontrol: charge swap to cgroup2

On 2015/12/15 17:30, Vladimir Davydov wrote: On Tue, Dec 15, 2015 at 12:12:40PM +0900, Kamezawa Hiroyuki wrote: On 2015/12/15 0:30, Michal Hocko wrote: On Thu 10-12-15 14:39:14, Vladimir Davydov wrote: In the legacy hierarchy we charge memsw, which is dubious, because: - memsw.limit must

Re: [PATCH 1/7] mm: memcontrol: charge swap to cgroup2

On 2015/12/15 17:30, Vladimir Davydov wrote: On Tue, Dec 15, 2015 at 12:12:40PM +0900, Kamezawa Hiroyuki wrote: On 2015/12/15 0:30, Michal Hocko wrote: On Thu 10-12-15 14:39:14, Vladimir Davydov wrote: In the legacy hierarchy we charge memsw, which is dubious, because: - memsw.limit must

Re: [PATCH 1/7] mm: memcontrol: charge swap to cgroup2

On 2015/12/15 23:50, Johannes Weiner wrote: On Tue, Dec 15, 2015 at 12:22:41PM +0900, Kamezawa Hiroyuki wrote: On 2015/12/15 4:42, Vladimir Davydov wrote: Anyway, if you don't trust a container you'd better set the hard memory limit so that it can't hurt others no matter what it runs and how

Re: [PATCH 1/7] mm: memcontrol: charge swap to cgroup2

On 2015/12/16 2:21, Michal Hocko wrote: I completely agree that malicious/untrusted users absolutely have to be capped by the hard limit. Then the separate swap limit would work for sure. But I am less convinced about usefulness of the rigid (to the global memory pressure) swap limit without

Re: [PATCH 1/7] mm: memcontrol: charge swap to cgroup2

On 2015/12/15 20:02, Vladimir Davydov wrote: On Tue, Dec 15, 2015 at 12:22:41PM +0900, Kamezawa Hiroyuki wrote: On 2015/12/15 4:42, Vladimir Davydov wrote: On Mon, Dec 14, 2015 at 04:30:37PM +0100, Michal Hocko wrote: On Thu 10-12-15 14:39:14, Vladimir Davydov wrote: In the legacy hierarchy

Re: [PATCH 1/7] mm: memcontrol: charge swap to cgroup2

On 2015/12/15 0:30, Michal Hocko wrote: On Thu 10-12-15 14:39:14, Vladimir Davydov wrote: In the legacy hierarchy we charge memsw, which is dubious, because: - memsw.limit must be >= memory.limit, so it is impossible to limit swap usage less than memory usage. Taking into account the

Re: [PATCH 1/7] mm: memcontrol: charge swap to cgroup2

On 2015/12/15 4:42, Vladimir Davydov wrote: On Mon, Dec 14, 2015 at 04:30:37PM +0100, Michal Hocko wrote: On Thu 10-12-15 14:39:14, Vladimir Davydov wrote: In the legacy hierarchy we charge memsw, which is dubious, because: - memsw.limit must be >= memory.limit, so it is impossible to limit

Re: [PATCH 1/7] mm: memcontrol: charge swap to cgroup2

On 2015/12/15 4:42, Vladimir Davydov wrote: On Mon, Dec 14, 2015 at 04:30:37PM +0100, Michal Hocko wrote: On Thu 10-12-15 14:39:14, Vladimir Davydov wrote: In the legacy hierarchy we charge memsw, which is dubious, because: - memsw.limit must be >= memory.limit, so it is impossible to limit

Re: [PATCH 1/7] mm: memcontrol: charge swap to cgroup2

On 2015/12/15 0:30, Michal Hocko wrote: On Thu 10-12-15 14:39:14, Vladimir Davydov wrote: In the legacy hierarchy we charge memsw, which is dubious, because: - memsw.limit must be >= memory.limit, so it is impossible to limit swap usage less than memory usage. Taking into account the

Re: [PATCH 1/7] mm: memcontrol: charge swap to cgroup2

On 2015/12/10 20:39, Vladimir Davydov wrote: > In the legacy hierarchy we charge memsw, which is dubious, because: > > - memsw.limit must be >= memory.limit, so it is impossible to limit > swap usage less than memory usage. Taking into account the fact that > the primary limiting

Re: [PATCH 1/7] mm: memcontrol: charge swap to cgroup2

On 2015/12/10 20:39, Vladimir Davydov wrote: > In the legacy hierarchy we charge memsw, which is dubious, because: > > - memsw.limit must be >= memory.limit, so it is impossible to limit > swap usage less than memory usage. Taking into account the fact that > the primary limiting

Re: [PATCH] mm: Introduce kernelcore=reliable option

On 2015/10/31 4:42, Luck, Tony wrote: If each memory controller has the same distance/latency, you (your firmware) don't need to allocate reliable memory per each memory controller. If distance is problem, another node should be allocated. ...is the behavior(splitting zone) really required ?

Re: [PATCH] mm: Introduce kernelcore=reliable option

On 2015/10/31 4:42, Luck, Tony wrote: If each memory controller has the same distance/latency, you (your firmware) don't need to allocate reliable memory per each memory controller. If distance is problem, another node should be allocated. ...is the behavior(splitting zone) really required ?

Re: [RFC 1/3] mm, oom: refactor oom detection

On 2015/10/30 17:23, Michal Hocko wrote: On Fri 30-10-15 14:23:59, KAMEZAWA Hiroyuki wrote: On 2015/10/30 0:17, mho...@kernel.org wrote: [...] @@ -3135,13 +3145,56 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, if (gfp_mask & __GFP_NORETRY) goto nor

Re: [PATCH] mm: Introduce kernelcore=reliable option

On 2015/10/23 10:44, Luck, Tony wrote: > First part of each memory controller. I have two memory controllers on each > node > If each memory controller has the same distance/latency, you (your firmware) don't need to allocate reliable memory per each memory controller. If distance is problem,

Re: [PATCH] mm: Introduce kernelcore=reliable option

On 2015/10/23 10:44, Luck, Tony wrote: > First part of each memory controller. I have two memory controllers on each > node > If each memory controller has the same distance/latency, you (your firmware) don't need to allocate reliable memory per each memory controller. If distance is problem,

Re: [RFC 1/3] mm, oom: refactor oom detection

On 2015/10/30 17:23, Michal Hocko wrote: On Fri 30-10-15 14:23:59, KAMEZAWA Hiroyuki wrote: On 2015/10/30 0:17, mho...@kernel.org wrote: [...] @@ -3135,13 +3145,56 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, if (gfp_mask & __GFP_NORETRY) goto nor

Re: [RFC 2/3] mm: throttle on IO only when there are too many dirty and writeback pages

On 2015/10/30 0:17, mho...@kernel.org wrote: > From: Michal Hocko > > wait_iff_congested has been used to throttle allocator before it retried > another round of direct reclaim to allow the writeback to make some > progress and prevent reclaim from looping over dirty/writeback pages > without

Re: [RFC 1/3] mm, oom: refactor oom detection

On 2015/10/30 0:17, mho...@kernel.org wrote: > From: Michal Hocko > > __alloc_pages_slowpath has traditionally relied on the direct reclaim > and did_some_progress as an indicator that it makes sense to retry > allocation rather than declaring OOM. shrink_zones had to rely on > zone_reclaimable

Re: [RFC 2/3] mm: throttle on IO only when there are too many dirty and writeback pages

On 2015/10/30 0:17, mho...@kernel.org wrote: > From: Michal Hocko > > wait_iff_congested has been used to throttle allocator before it retried > another round of direct reclaim to allow the writeback to make some > progress and prevent reclaim from looping over dirty/writeback

Re: [RFC 1/3] mm, oom: refactor oom detection

On 2015/10/30 0:17, mho...@kernel.org wrote: > From: Michal Hocko > > __alloc_pages_slowpath has traditionally relied on the direct reclaim > and did_some_progress as an indicator that it makes sense to retry > allocation rather than declaring OOM. shrink_zones had to rely on >

Re: [PATCH] mm: Introduce kernelcore=reliable option

On 2015/10/22 3:17, Luck, Tony wrote: + if (reliable_kernelcore) { + for_each_memblock(memory, r) { + if (memblock_is_mirror(r)) + continue; Should we have a safety check here that there is some mirrored memory? If you

Re: [PATCH] mm: Introduce kernelcore=reliable option

On 2015/10/22 3:17, Luck, Tony wrote: + if (reliable_kernelcore) { + for_each_memblock(memory, r) { + if (memblock_is_mirror(r)) + continue; Should we have a safety check here that there is some mirrored memory? If you

Re: [PATCH][RFC] mm: Introduce kernelcore=reliable option

On 2015/10/09 19:36, Xishi Qiu wrote: On 2015/10/9 17:24, Kamezawa Hiroyuki wrote: On 2015/10/09 15:46, Xishi Qiu wrote: On 2015/10/9 22:56, Taku Izumi wrote: Xeon E7 v3 based systems supports Address Range Mirroring and UEFI BIOS complied with UEFI spec 2.5 can notify which ranges

Re: [PATCH][RFC] mm: Introduce kernelcore=reliable option

On 2015/10/09 19:36, Xishi Qiu wrote: On 2015/10/9 17:24, Kamezawa Hiroyuki wrote: On 2015/10/09 15:46, Xishi Qiu wrote: On 2015/10/9 22:56, Taku Izumi wrote: Xeon E7 v3 based systems supports Address Range Mirroring and UEFI BIOS complied with UEFI spec 2.5 can notify which ranges

Re: [PATCH][RFC] mm: Introduce kernelcore=reliable option

On 2015/10/09 15:46, Xishi Qiu wrote: On 2015/10/9 22:56, Taku Izumi wrote: Xeon E7 v3 based systems supports Address Range Mirroring and UEFI BIOS complied with UEFI spec 2.5 can notify which ranges are reliable (mirrored) via EFI memory map. Now Linux kernel utilize its information and

Re: [Intel-wired-lan] [Patch V3 5/9] i40e: Use numa_mem_id() to better support memoryless node

On 2015/10/09 14:52, Jiang Liu wrote: On 2015/10/9 4:20, Andrew Morton wrote: On Wed, 19 Aug 2015 17:18:15 -0700 (PDT) David Rientjes wrote: On Wed, 19 Aug 2015, Patil, Kiran wrote: Acked-by: Kiran Patil Where's the call to preempt_disable() to prevent kernels with preemption from

Re: [Intel-wired-lan] [Patch V3 5/9] i40e: Use numa_mem_id() to better support memoryless node

On 2015/10/09 14:52, Jiang Liu wrote: On 2015/10/9 4:20, Andrew Morton wrote: On Wed, 19 Aug 2015 17:18:15 -0700 (PDT) David Rientjes wrote: On Wed, 19 Aug 2015, Patil, Kiran wrote: Acked-by: Kiran Patil Where's the call to preempt_disable()

Re: [PATCH][RFC] mm: Introduce kernelcore=reliable option

On 2015/10/09 15:46, Xishi Qiu wrote: On 2015/10/9 22:56, Taku Izumi wrote: Xeon E7 v3 based systems supports Address Range Mirroring and UEFI BIOS complied with UEFI spec 2.5 can notify which ranges are reliable (mirrored) via EFI memory map. Now Linux kernel utilize its information and

Re: [PATCH 03/11] x86/mm/hotplug: Don't remove PGD entries in remove_pagetable()

On 2015/09/22 15:23, Ingo Molnar wrote: > So when memory hotplug removes a piece of physical memory from pagetable > mappings, it also frees the underlying PGD entry. > > This complicates PGD management, so don't do this. We can keep the > PGD mapped and the PUD table all clear - it's only a

Re: [PATCH 03/11] x86/mm/hotplug: Don't remove PGD entries in remove_pagetable()

On 2015/09/22 15:23, Ingo Molnar wrote: > So when memory hotplug removes a piece of physical memory from pagetable > mappings, it also frees the underlying PGD entry. > > This complicates PGD management, so don't do this. We can keep the > PGD mapped and the PUD table all clear - it's only a

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

On 2015/08/25 8:15, Paul Turner wrote: On Mon, Aug 24, 2015 at 3:49 PM, Tejun Heo wrote: Hello, On Mon, Aug 24, 2015 at 03:03:05PM -0700, Paul Turner wrote: Hmm... I was hoping for an actual configurations and usage scenarios. Preferably something people can set up and play with. This is

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

On 2015/08/25 8:15, Paul Turner wrote: On Mon, Aug 24, 2015 at 3:49 PM, Tejun Heo t...@kernel.org wrote: Hello, On Mon, Aug 24, 2015 at 03:03:05PM -0700, Paul Turner wrote: Hmm... I was hoping for an actual configurations and usage scenarios. Preferably something people can set up and play

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

On 2015/08/19 5:31, Tejun Heo wrote: Hello, Paul. On Mon, Aug 17, 2015 at 09:03:30PM -0700, Paul Turner wrote: 2) Control within an address-space. For subsystems with fungible resources, e.g. CPU, it can be useful for an address space to partition its own threads. Losing the capability to do

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

On 2015/08/19 5:31, Tejun Heo wrote: Hello, Paul. On Mon, Aug 17, 2015 at 09:03:30PM -0700, Paul Turner wrote: 2) Control within an address-space. For subsystems with fungible resources, e.g. CPU, it can be useful for an address space to partition its own threads. Losing the capability to do

Re: [PATCH 0/3] Make workingset detection logic memcg aware

On 2015/08/10 17:14, Vladimir Davydov wrote: On Sun, Aug 09, 2015 at 11:12:25PM +0900, Kamezawa Hiroyuki wrote: On 2015/08/08 22:05, Vladimir Davydov wrote: On Fri, Aug 07, 2015 at 10:38:16AM +0900, Kamezawa Hiroyuki wrote: ... All ? hmm. It seems that mixture of record of global memory

Re: [PATCH 0/3] Make workingset detection logic memcg aware

On 2015/08/10 17:14, Vladimir Davydov wrote: On Sun, Aug 09, 2015 at 11:12:25PM +0900, Kamezawa Hiroyuki wrote: On 2015/08/08 22:05, Vladimir Davydov wrote: On Fri, Aug 07, 2015 at 10:38:16AM +0900, Kamezawa Hiroyuki wrote: ... All ? hmm. It seems that mixture of record of global memory

Re: [PATCH 0/3] Make workingset detection logic memcg aware

On 2015/08/08 22:05, Vladimir Davydov wrote: On Fri, Aug 07, 2015 at 10:38:16AM +0900, Kamezawa Hiroyuki wrote: On 2015/08/06 17:59, Vladimir Davydov wrote: On Wed, Aug 05, 2015 at 10:34:58AM +0900, Kamezawa Hiroyuki wrote: I wonder, rather than collecting more data, rough calculation can

Re: [PATCH 0/3] Make workingset detection logic memcg aware

On 2015/08/08 22:05, Vladimir Davydov wrote: On Fri, Aug 07, 2015 at 10:38:16AM +0900, Kamezawa Hiroyuki wrote: On 2015/08/06 17:59, Vladimir Davydov wrote: On Wed, Aug 05, 2015 at 10:34:58AM +0900, Kamezawa Hiroyuki wrote: I wonder, rather than collecting more data, rough calculation can

Re: [PATCH 0/3] Make workingset detection logic memcg aware

On 2015/08/06 17:59, Vladimir Davydov wrote: On Wed, Aug 05, 2015 at 10:34:58AM +0900, Kamezawa Hiroyuki wrote: Reading discussion, I feel storing more data is difficult, too. Yep, even with the current 16-bit memcg id. Things would get even worse if we wanted to extend it one day (will we

Re: [PATCH 0/3] Make workingset detection logic memcg aware

On 2015/08/06 17:59, Vladimir Davydov wrote: On Wed, Aug 05, 2015 at 10:34:58AM +0900, Kamezawa Hiroyuki wrote: Reading discussion, I feel storing more data is difficult, too. Yep, even with the current 16-bit memcg id. Things would get even worse if we wanted to extend it one day (will we

Re: [PATCH v2 1/3] cgroup: define controller file conventions

On 2015/08/05 16:47, Michal Hocko wrote: On Wed 05-08-15 09:39:40, KAMEZAWA Hiroyuki wrote: [...] so, for memory controller, we'll have We currently have only current, low, high, max and events currently. All other knobs are either deprecated or waiting for a usecase to emerge before they get

Re: [PATCH v2 1/3] cgroup: define controller file conventions

On 2015/08/05 16:47, Michal Hocko wrote: On Wed 05-08-15 09:39:40, KAMEZAWA Hiroyuki wrote: [...] so, for memory controller, we'll have We currently have only current, low, high, max and events currently. All other knobs are either deprecated or waiting for a usecase to emerge before they get

Re: [PATCH 0/3] Make workingset detection logic memcg aware

On 2015/08/03 21:04, Vladimir Davydov wrote: > Hi, > > Currently, workingset detection logic is not memcg aware - inactive_age > is maintained per zone. As a result, if memory cgroups are used, > refaulted file pages are activated randomly. This patch set makes > inactive_age per lruvec so that

Re: [PATCH v2 1/3] cgroup: define controller file conventions

On 2015/08/05 4:31, Tejun Heo wrote: From 6abc8ca19df0078de17dc38340db3002ed489ce7 Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Tue, 4 Aug 2015 15:20:55 -0400 Traditionally, each cgroup controller implemented whatever interface it wanted leading to interfaces which are widely inconsistent.

Re: [PATCH v2 1/3] cgroup: define controller file conventions

On 2015/08/05 4:31, Tejun Heo wrote: From 6abc8ca19df0078de17dc38340db3002ed489ce7 Mon Sep 17 00:00:00 2001 From: Tejun Heo t...@kernel.org Date: Tue, 4 Aug 2015 15:20:55 -0400 Traditionally, each cgroup controller implemented whatever interface it wanted leading to interfaces which are widely

Re: [PATCH 0/3] Make workingset detection logic memcg aware

On 2015/08/03 21:04, Vladimir Davydov wrote: Hi, Currently, workingset detection logic is not memcg aware - inactive_age is maintained per zone. As a result, if memory cgroups are used, refaulted file pages are activated randomly. This patch set makes inactive_age per lruvec so that

Re: [RFC v2 PATCH 2/8] mm: introduce MIGRATE_MIRROR to manage the mirrored pages

On 2015/06/30 11:45, Xishi Qiu wrote: On 2015/6/29 15:32, Kamezawa Hiroyuki wrote: On 2015/06/27 11:24, Xishi Qiu wrote: This patch introduces a new migratetype called "MIGRATE_MIRROR", it is used to allocate mirrored pages. When cat /proc/pagetypeinfo, you can see the count of fre

Re: [RFC v2 PATCH 2/8] mm: introduce MIGRATE_MIRROR to manage the mirrored pages

On 2015/06/30 11:45, Xishi Qiu wrote: On 2015/6/29 15:32, Kamezawa Hiroyuki wrote: On 2015/06/27 11:24, Xishi Qiu wrote: This patch introduces a new migratetype called MIGRATE_MIRROR, it is used to allocate mirrored pages. When cat /proc/pagetypeinfo, you can see the count of free mirrored

Re: [RFC v2 PATCH 7/8] mm: add the buddy system interface

On 2015/06/30 10:31, Xishi Qiu wrote: On 2015/6/30 9:01, Kamezawa Hiroyuki wrote: On 2015/06/30 8:11, Luck, Tony wrote: @@ -814,7 +814,7 @@ int __init_memblock memblock_clear_hotplug(phys_addr_t base, phys_addr_t size) */ int __init_memblock memblock_mark_mirror(phys_addr_t base

Re: [RFC v2 PATCH 7/8] mm: add the buddy system interface

On 2015/06/30 8:11, Luck, Tony wrote: @@ -814,7 +814,7 @@ int __init_memblock memblock_clear_hotplug(phys_addr_t base, phys_addr_t size) */ int __init_memblock memblock_mark_mirror(phys_addr_t base, phys_addr_t size) { - system_has_some_mirror = true; +

Re: [RFC v2 PATCH 4/8] mm: add mirrored memory to buddy system

On 2015/06/27 11:25, Xishi Qiu wrote: Before free bootmem, set mirrored pageblock's migratetype to MIGRATE_MIRROR, so they could free to buddy system's MIGRATE_MIRROR list. When set reserved memory, skip the mirrored memory. Signed-off-by: Xishi Qiu --- include/linux/memblock.h | 3 +++

Re: [RFC v2 PATCH 2/8] mm: introduce MIGRATE_MIRROR to manage the mirrored pages

On 2015/06/27 11:24, Xishi Qiu wrote: This patch introduces a new migratetype called "MIGRATE_MIRROR", it is used to allocate mirrored pages. When cat /proc/pagetypeinfo, you can see the count of free mirrored blocks. Signed-off-by: Xishi Qiu My fear about this approarch is that this may

Re: [RFC v2 PATCH 1/8] mm: add a new config to manage the code

hanks, -Kame >From 88213b0f76e2f603c5a38690cbd85a4df1e646ba Mon Sep 17 00:00:00 2001 From: KAMEZAWA Hiroyuki Date: Mon, 29 Jun 2015 15:35:47 +0900 Subject: [PATCH] add a new config option for memory mirror Add a new config option "CONFIG_MEMORY_MIRROR" for kernel assisted memory mirroring. In UEFI2.5 spec, Address

Re: [RFC v2 PATCH 1/8] mm: add a new config to manage the code

88213b0f76e2f603c5a38690cbd85a4df1e646ba Mon Sep 17 00:00:00 2001 From: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com Date: Mon, 29 Jun 2015 15:35:47 +0900 Subject: [PATCH] add a new config option for memory mirror Add a new config option CONFIG_MEMORY_MIRROR for kernel assisted memory mirroring. In UEFI2.5 spec

Re: [RFC v2 PATCH 4/8] mm: add mirrored memory to buddy system

On 2015/06/27 11:25, Xishi Qiu wrote: Before free bootmem, set mirrored pageblock's migratetype to MIGRATE_MIRROR, so they could free to buddy system's MIGRATE_MIRROR list. When set reserved memory, skip the mirrored memory. Signed-off-by: Xishi Qiu qiuxi...@huawei.com ---

Re: [RFC v2 PATCH 2/8] mm: introduce MIGRATE_MIRROR to manage the mirrored pages

On 2015/06/27 11:24, Xishi Qiu wrote: This patch introduces a new migratetype called MIGRATE_MIRROR, it is used to allocate mirrored pages. When cat /proc/pagetypeinfo, you can see the count of free mirrored blocks. Signed-off-by: Xishi Qiu qiuxi...@huawei.com My fear about this approarch is

Re: [RFC v2 PATCH 7/8] mm: add the buddy system interface

On 2015/06/30 10:31, Xishi Qiu wrote: On 2015/6/30 9:01, Kamezawa Hiroyuki wrote: On 2015/06/30 8:11, Luck, Tony wrote: @@ -814,7 +814,7 @@ int __init_memblock memblock_clear_hotplug(phys_addr_t base, phys_addr_t size) */ int __init_memblock memblock_mark_mirror(phys_addr_t base

Re: [RFC v2 PATCH 7/8] mm: add the buddy system interface

On 2015/06/30 8:11, Luck, Tony wrote: @@ -814,7 +814,7 @@ int __init_memblock memblock_clear_hotplug(phys_addr_t base, phys_addr_t size) */ int __init_memblock memblock_mark_mirror(phys_addr_t base, phys_addr_t size) { - system_has_some_mirror = true; +

Re: [RFC PATCH 10/12] mm: add the buddy system interface

On 2015/06/26 10:43, Xishi Qiu wrote: On 2015/6/26 7:54, Kamezawa Hiroyuki wrote: On 2015/06/25 18:44, Xishi Qiu wrote: On 2015/6/10 11:06, Kamezawa Hiroyuki wrote: On 2015/06/09 19:04, Xishi Qiu wrote: On 2015/6/9 15:12, Kamezawa Hiroyuki wrote: On 2015/06/04 22:04, Xishi Qiu wrote

Re: [RFC PATCH 10/12] mm: add the buddy system interface

On 2015/06/26 10:43, Xishi Qiu wrote: On 2015/6/26 7:54, Kamezawa Hiroyuki wrote: On 2015/06/25 18:44, Xishi Qiu wrote: On 2015/6/10 11:06, Kamezawa Hiroyuki wrote: On 2015/06/09 19:04, Xishi Qiu wrote: On 2015/6/9 15:12, Kamezawa Hiroyuki wrote: On 2015/06/04 22:04, Xishi Qiu wrote

Re: [RFC PATCH 10/12] mm: add the buddy system interface

On 2015/06/25 18:44, Xishi Qiu wrote: On 2015/6/10 11:06, Kamezawa Hiroyuki wrote: On 2015/06/09 19:04, Xishi Qiu wrote: On 2015/6/9 15:12, Kamezawa Hiroyuki wrote: On 2015/06/04 22:04, Xishi Qiu wrote: Add the buddy system interface for address range mirroring feature. Allocate mirrored

Re: [RFC PATCH 10/12] mm: add the buddy system interface

On 2015/06/25 18:44, Xishi Qiu wrote: On 2015/6/10 11:06, Kamezawa Hiroyuki wrote: On 2015/06/09 19:04, Xishi Qiu wrote: On 2015/6/9 15:12, Kamezawa Hiroyuki wrote: On 2015/06/04 22:04, Xishi Qiu wrote: Add the buddy system interface for address range mirroring feature. Allocate mirrored

Re: [RFC PATCH 10/12] mm: add the buddy system interface

On 2015/06/16 2:20, Luck, Tony wrote: On Mon, Jun 15, 2015 at 05:47:27PM +0900, Kamezawa Hiroyuki wrote: So, there are 3 ideas. (1) kernel only from MIRROR / user only from MOVABLE (Tony) (2) kernel only from MIRROR / user from MOVABLE + MIRROR(ASAP) (AKPM suggested) This makes use

Re: [RFC PATCH 10/12] mm: add the buddy system interface

On 2015/06/11 5:40, Luck, Tony wrote: I guess, mirrored memory should be allocated if !__GFP_HIGHMEM or !__GFP_MOVABLE HIGHMEM shouldn't matter - partial memory mirror only makes any sense on X86_64 systems ... 32-bit kernels don't even boot on systems with 64GB, and the minimum rational

Re: [RFC PATCH 10/12] mm: add the buddy system interface

On 2015/06/11 5:40, Luck, Tony wrote: I guess, mirrored memory should be allocated if !__GFP_HIGHMEM or !__GFP_MOVABLE HIGHMEM shouldn't matter - partial memory mirror only makes any sense on X86_64 systems ... 32-bit kernels don't even boot on systems with 64GB, and the minimum rational

Re: [RFC PATCH 10/12] mm: add the buddy system interface

On 2015/06/16 2:20, Luck, Tony wrote: On Mon, Jun 15, 2015 at 05:47:27PM +0900, Kamezawa Hiroyuki wrote: So, there are 3 ideas. (1) kernel only from MIRROR / user only from MOVABLE (Tony) (2) kernel only from MIRROR / user from MOVABLE + MIRROR(ASAP) (AKPM suggested) This makes use

Re: [RFC PATCH 08/12] mm: use mirrorable to switch allocate mirrored memory

On 2015/06/09 19:09, Xishi Qiu wrote: On 2015/6/9 15:06, Kamezawa Hiroyuki wrote: On 2015/06/04 22:02, Xishi Qiu wrote: Add a new interface in path /proc/sys/vm/mirrorable. When set to 1, it means we should allocate mirrored memory for both user and kernel processes. Signed-off-by: Xishi Qiu

Re: [RFC PATCH 01/12] mm: add a new config to manage the code

On 2015/06/09 19:10, Xishi Qiu wrote: On 2015/6/9 14:44, Kamezawa Hiroyuki wrote: On 2015/06/04 21:56, Xishi Qiu wrote: This patch introduces a new config called "CONFIG_ACPI_MIRROR_MEMORY", it is used to on/off the feature. Signed-off-by: Xishi Qiu --- mm/Kconfig | 8

Re: [RFC PATCH 10/12] mm: add the buddy system interface

On 2015/06/09 19:04, Xishi Qiu wrote: On 2015/6/9 15:12, Kamezawa Hiroyuki wrote: On 2015/06/04 22:04, Xishi Qiu wrote: Add the buddy system interface for address range mirroring feature. Allocate mirrored pages in MIGRATE_MIRROR list. If there is no mirrored pages left, use other types pages

Re: [RFC PATCH 10/12] mm: add the buddy system interface

On 2015/06/04 22:04, Xishi Qiu wrote: Add the buddy system interface for address range mirroring feature. Allocate mirrored pages in MIGRATE_MIRROR list. If there is no mirrored pages left, use other types pages. Signed-off-by: Xishi Qiu --- mm/page_alloc.c | 40

Re: [RFC PATCH 08/12] mm: use mirrorable to switch allocate mirrored memory

On 2015/06/04 22:02, Xishi Qiu wrote: Add a new interface in path /proc/sys/vm/mirrorable. When set to 1, it means we should allocate mirrored memory for both user and kernel processes. Signed-off-by: Xishi Qiu I can't see why do we need this switch. If this is set, all GFP_HIGHUSER will

Re: [RFC PATCH 07/12] mm: introduce __GFP_MIRROR to allocate mirrored pages

On 2015/06/04 22:02, Xishi Qiu wrote: This patch introduces a new gfp flag called "__GFP_MIRROR", it is used to allocate mirrored pages through buddy system. Signed-off-by: Xishi Qiu In Tony's original proposal, the motivation was to mirror all kernel memory. Is the purpose of this patch

  1   2   3   4   5   6   7   8   9   10   >