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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
>>
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
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:
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
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
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.
>>
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 ?
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 ?
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
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,
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,
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
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
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
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
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
>
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
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
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
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
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
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
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()
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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;
+
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 +++
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
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
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
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
---
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
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
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;
+
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
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
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
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
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
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
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
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
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
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
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
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
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
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 - 100 of 1415 matches
Mail list logo