On Tue, Sep 23 2014, Johannes Weiner wrote:
> On Mon, Sep 22, 2014 at 10:52:50PM -0700, Greg Thelen wrote:
>>
>> On Fri, Sep 19 2014, Johannes Weiner wrote:
>>
>> > In a memcg with even just moderate cache pressure, success rates for
>> > transparent huge page allocations drop to zero, wasting
On Tue, Sep 23, 2014 at 07:48:27AM -0400, Johannes Weiner wrote:
> On Tue, Sep 23, 2014 at 12:29:27PM +0400, Vladimir Davydov wrote:
> > On Mon, Sep 22, 2014 at 10:52:50PM -0700, Greg Thelen wrote:
> > > In this condition, if res usage is at limit then there's no point in
> > > swapping because
On Tue, Sep 23, 2014 at 12:29:27PM +0400, Vladimir Davydov wrote:
> [sorry for butting in, but I think I can answer your question]
>
> On Mon, Sep 22, 2014 at 10:52:50PM -0700, Greg Thelen wrote:
> >
> > On Fri, Sep 19 2014, Johannes Weiner wrote:
> >
> > > In a memcg with even just moderate
On Tue, Sep 23, 2014 at 12:29:27PM +0400, Vladimir Davydov wrote:
> On Mon, Sep 22, 2014 at 10:52:50PM -0700, Greg Thelen wrote:
> > In this condition, if res usage is at limit then there's no point in
> > swapping because memsw.usage is already maximal. Prior to this patch
> > I think the kernel
On Mon, Sep 22, 2014 at 10:52:50PM -0700, Greg Thelen wrote:
>
> On Fri, Sep 19 2014, Johannes Weiner wrote:
>
> > In a memcg with even just moderate cache pressure, success rates for
> > transparent huge page allocations drop to zero, wasting a lot of
> > effort that the allocator puts into
[sorry for butting in, but I think I can answer your question]
On Mon, Sep 22, 2014 at 10:52:50PM -0700, Greg Thelen wrote:
>
> On Fri, Sep 19 2014, Johannes Weiner wrote:
>
> > In a memcg with even just moderate cache pressure, success rates for
> > transparent huge page allocations drop to
On Fri, Sep 19 2014, Johannes Weiner wrote:
> In a memcg with even just moderate cache pressure, success rates for
> transparent huge page allocations drop to zero, wasting a lot of
> effort that the allocator puts into assembling these pages.
>
> The reason for this is that the memcg reclaim
On Fri, Sep 19 2014, Johannes Weiner wrote:
In a memcg with even just moderate cache pressure, success rates for
transparent huge page allocations drop to zero, wasting a lot of
effort that the allocator puts into assembling these pages.
The reason for this is that the memcg reclaim code
[sorry for butting in, but I think I can answer your question]
On Mon, Sep 22, 2014 at 10:52:50PM -0700, Greg Thelen wrote:
On Fri, Sep 19 2014, Johannes Weiner wrote:
In a memcg with even just moderate cache pressure, success rates for
transparent huge page allocations drop to zero,
On Mon, Sep 22, 2014 at 10:52:50PM -0700, Greg Thelen wrote:
On Fri, Sep 19 2014, Johannes Weiner wrote:
In a memcg with even just moderate cache pressure, success rates for
transparent huge page allocations drop to zero, wasting a lot of
effort that the allocator puts into assembling
On Tue, Sep 23, 2014 at 12:29:27PM +0400, Vladimir Davydov wrote:
On Mon, Sep 22, 2014 at 10:52:50PM -0700, Greg Thelen wrote:
In this condition, if res usage is at limit then there's no point in
swapping because memsw.usage is already maximal. Prior to this patch
I think the kernel did
On Tue, Sep 23, 2014 at 12:29:27PM +0400, Vladimir Davydov wrote:
[sorry for butting in, but I think I can answer your question]
On Mon, Sep 22, 2014 at 10:52:50PM -0700, Greg Thelen wrote:
On Fri, Sep 19 2014, Johannes Weiner wrote:
In a memcg with even just moderate cache
On Tue, Sep 23, 2014 at 07:48:27AM -0400, Johannes Weiner wrote:
On Tue, Sep 23, 2014 at 12:29:27PM +0400, Vladimir Davydov wrote:
On Mon, Sep 22, 2014 at 10:52:50PM -0700, Greg Thelen wrote:
In this condition, if res usage is at limit then there's no point in
swapping because memsw.usage
On Tue, Sep 23 2014, Johannes Weiner wrote:
On Mon, Sep 22, 2014 at 10:52:50PM -0700, Greg Thelen wrote:
On Fri, Sep 19 2014, Johannes Weiner wrote:
In a memcg with even just moderate cache pressure, success rates for
transparent huge page allocations drop to zero, wasting a lot of
On Fri, Sep 19, 2014 at 09:20:40AM -0400, Johannes Weiner wrote:
> In a memcg with even just moderate cache pressure, success rates for
> transparent huge page allocations drop to zero, wasting a lot of
> effort that the allocator puts into assembling these pages.
>
> The reason for this is that
On Fri, Sep 19, 2014 at 09:20:40AM -0400, Johannes Weiner wrote:
In a memcg with even just moderate cache pressure, success rates for
transparent huge page allocations drop to zero, wasting a lot of
effort that the allocator puts into assembling these pages.
The reason for this is that the
In a memcg with even just moderate cache pressure, success rates for
transparent huge page allocations drop to zero, wasting a lot of
effort that the allocator puts into assembling these pages.
The reason for this is that the memcg reclaim code was never designed
for higher-order charges. It
In a memcg with even just moderate cache pressure, success rates for
transparent huge page allocations drop to zero, wasting a lot of
effort that the allocator puts into assembling these pages.
The reason for this is that the memcg reclaim code was never designed
for higher-order charges. It
18 matches
Mail list logo
