On Fri 23-01-15 12:03:53, Johannes Weiner wrote:
> On Tue, Jan 20, 2015 at 12:00:11PM -0500, Tejun Heo wrote:
> > Hello,
> >
> > On Tue, Jan 20, 2015 at 9:36 AM, Michal Hocko wrote:
> > > On Tue 20-01-15 09:30:02, Johannes Weiner wrote:
> > > [...]
> > >> Another possibility would be "infinity",
On Tue, Jan 20, 2015 at 12:00:11PM -0500, Tejun Heo wrote:
> Hello,
>
> On Tue, Jan 20, 2015 at 9:36 AM, Michal Hocko wrote:
> > On Tue 20-01-15 09:30:02, Johannes Weiner wrote:
> > [...]
> >> Another possibility would be "infinity",
> >
> > yes infinity definitely sounds much better to me.
>
>
Hello,
On Tue, Jan 20, 2015 at 9:36 AM, Michal Hocko wrote:
> On Tue 20-01-15 09:30:02, Johannes Weiner wrote:
> [...]
>> Another possibility would be "infinity",
>
> yes infinity definitely sounds much better to me.
FWIW, I prefer "max". It's shorter and clear enough. I don't think
there's anyt
On Tue, Jan 20, 2015 at 03:31:19PM +0100, Michal Hocko wrote:
> On Tue 20-01-15 09:16:28, Johannes Weiner wrote:
> > On Tue, Jan 20, 2015 at 02:25:19PM +0100, Michal Hocko wrote:
> [...]
> > > Is this planned to be folded into the original patch or go on its own. I
> > > am OK with both ways, maybe
On Tue 20-01-15 09:30:02, Johannes Weiner wrote:
[...]
> Another possibility would be "infinity",
yes infinity definitely sounds much better to me.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kerne
On Tue 20-01-15 09:16:28, Johannes Weiner wrote:
> On Tue, Jan 20, 2015 at 02:25:19PM +0100, Michal Hocko wrote:
[...]
> > Is this planned to be folded into the original patch or go on its own. I
> > am OK with both ways, maybe having it separate would be better from
> > documentation POV.
>
> I s
On Tue, Jan 20, 2015 at 02:37:11PM +0100, Michal Hocko wrote:
> On Sat 17-01-15 10:21:47, Johannes Weiner wrote:
> > The "none" name for the low-boundary 0 and the high-boundary maximum
> > value can be confusing.
> >
> > Just leave the low boundary at 0, and give the highest-possible
> > boundary
On Tue, Jan 20, 2015 at 02:25:19PM +0100, Michal Hocko wrote:
> On Sat 17-01-15 10:21:19, Johannes Weiner wrote:
> > High limit reclaim can currently overscan in proportion to how many
> > charges are happening concurrently. Tone it down such that charges
> > don't target the entire high-boundary
On Sat 17-01-15 10:21:47, Johannes Weiner wrote:
> The "none" name for the low-boundary 0 and the high-boundary maximum
> value can be confusing.
>
> Just leave the low boundary at 0, and give the highest-possible
> boundary value the name "max" that means the same for controls.
max might be conf
On Sat 17-01-15 10:21:19, Johannes Weiner wrote:
> High limit reclaim can currently overscan in proportion to how many
> charges are happening concurrently. Tone it down such that charges
> don't target the entire high-boundary excess, but instead only the
> pages they charged themselves when exce
High limit reclaim can currently overscan in proportion to how many
charges are happening concurrently. Tone it down such that charges
don't target the entire high-boundary excess, but instead only the
pages they charged themselves when excess is detected.
Reported-by: Michal Hocko
Signed-off-by
The "none" name for the low-boundary 0 and the high-boundary maximum
value can be confusing.
Just leave the low boundary at 0, and give the highest-possible
boundary value the name "max" that means the same for controls.
Reported-by: Michal Hocko
Signed-off-by: Johannes Weiner
---
Documentatio
Document and rationalize where the default hierarchy interface differs
from the traditional memory cgroups interface.
Signed-off-by: Johannes Weiner
---
Documentation/cgroups/unified-hierarchy.txt | 80 +
1 file changed, 80 insertions(+)
diff --git a/Documentation/cg
13 matches
Mail list logo
