On Wed, May 06, 2015 at 04:58:14PM +0200, Michal Hocko wrote:
> On Tue 05-05-15 12:45:42, Vladimir Davydov wrote:
> [...]
> > diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> > index 97a9373e61e8..37c422df2a0f 100644
> > --- a/include/linux/gfp.h
> > +++ b/include/linux/gfp.h
> > @@ -30,6
On Wed, May 06, 2015 at 03:46:20PM +0200, Michal Hocko wrote:
> On Wed 06-05-15 09:16:22, Johannes Weiner wrote:
> > On Wed, May 06, 2015 at 01:59:41PM +0200, Michal Hocko wrote:
> > > On Tue 05-05-15 12:45:42, Vladimir Davydov wrote:
> > > > Not all kmem allocations should be accounted to memcg.
On Tue 05-05-15 12:45:42, Vladimir Davydov wrote:
[...]
> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index 97a9373e61e8..37c422df2a0f 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -30,6 +30,7 @@ struct vm_area_struct;
> #define ___GFP_HARDWALL
On Wed 06-05-15 17:29:51, Vladimir Davydov wrote:
[...]
> My point is that MEMCG is the only subsystem of the kernel that tries to
> do full memory accounting, and there is no point in introducing another
> one, because we already have it.
Then I really do not get why the gfp flag cannot be
On Wed, May 06, 2015 at 03:55:20PM +0200, Michal Hocko wrote:
> On Wed 06-05-15 16:25:10, Vladimir Davydov wrote:
> > On Wed, May 06, 2015 at 02:35:41PM +0200, Michal Hocko wrote:
[...]
> > > NOACCOUNT doesn't imply kmem at all so it is not clear who is in charge
> > > of the accounting.
> >
> >
On Wed 06-05-15 16:25:10, Vladimir Davydov wrote:
> On Wed, May 06, 2015 at 02:35:41PM +0200, Michal Hocko wrote:
> > On Wed 06-05-15 15:24:31, Vladimir Davydov wrote:
[...]
> > > I don't think making this flag per-cache is an option either, but for
> > > another reason - it would not be possible
On Wed 06-05-15 09:16:22, Johannes Weiner wrote:
> On Wed, May 06, 2015 at 01:59:41PM +0200, Michal Hocko wrote:
> > On Tue 05-05-15 12:45:42, Vladimir Davydov wrote:
> > > Not all kmem allocations should be accounted to memcg. The following
> > > patch gives an example when accounting of a
On Wed, May 06, 2015 at 02:35:41PM +0200, Michal Hocko wrote:
> On Wed 06-05-15 15:24:31, Vladimir Davydov wrote:
> > On Wed, May 06, 2015 at 01:59:41PM +0200, Michal Hocko wrote:
> > > On Tue 05-05-15 12:45:42, Vladimir Davydov wrote:
> > > > Not all kmem allocations should be accounted to memcg.
On Wed, May 06, 2015 at 01:59:41PM +0200, Michal Hocko wrote:
> On Tue 05-05-15 12:45:42, Vladimir Davydov wrote:
> > Not all kmem allocations should be accounted to memcg. The following
> > patch gives an example when accounting of a certain type of allocations
> > to memcg can effectively result
On Wed 06-05-15 15:24:31, Vladimir Davydov wrote:
> On Wed, May 06, 2015 at 01:59:41PM +0200, Michal Hocko wrote:
> > On Tue 05-05-15 12:45:42, Vladimir Davydov wrote:
> > > Not all kmem allocations should be accounted to memcg. The following
> > > patch gives an example when accounting of a
On Wed, May 06, 2015 at 01:59:41PM +0200, Michal Hocko wrote:
> On Tue 05-05-15 12:45:42, Vladimir Davydov wrote:
> > Not all kmem allocations should be accounted to memcg. The following
> > patch gives an example when accounting of a certain type of allocations
> > to memcg can effectively result
On Tue 05-05-15 12:45:42, Vladimir Davydov wrote:
> Not all kmem allocations should be accounted to memcg. The following
> patch gives an example when accounting of a certain type of allocations
> to memcg can effectively result in a memory leak.
> This patch adds the __GFP_NOACCOUNT flag which
On Tue 05-05-15 12:45:42, Vladimir Davydov wrote:
Not all kmem allocations should be accounted to memcg. The following
patch gives an example when accounting of a certain type of allocations
to memcg can effectively result in a memory leak.
This patch adds the __GFP_NOACCOUNT flag which if
On Wed, May 06, 2015 at 01:59:41PM +0200, Michal Hocko wrote:
On Tue 05-05-15 12:45:42, Vladimir Davydov wrote:
Not all kmem allocations should be accounted to memcg. The following
patch gives an example when accounting of a certain type of allocations
to memcg can effectively result in a
On Wed 06-05-15 15:24:31, Vladimir Davydov wrote:
On Wed, May 06, 2015 at 01:59:41PM +0200, Michal Hocko wrote:
On Tue 05-05-15 12:45:42, Vladimir Davydov wrote:
Not all kmem allocations should be accounted to memcg. The following
patch gives an example when accounting of a certain type
On Wed, May 06, 2015 at 01:59:41PM +0200, Michal Hocko wrote:
On Tue 05-05-15 12:45:42, Vladimir Davydov wrote:
Not all kmem allocations should be accounted to memcg. The following
patch gives an example when accounting of a certain type of allocations
to memcg can effectively result in a
On Wed 06-05-15 16:25:10, Vladimir Davydov wrote:
On Wed, May 06, 2015 at 02:35:41PM +0200, Michal Hocko wrote:
On Wed 06-05-15 15:24:31, Vladimir Davydov wrote:
[...]
I don't think making this flag per-cache is an option either, but for
another reason - it would not be possible to merge
On Wed, May 06, 2015 at 02:35:41PM +0200, Michal Hocko wrote:
On Wed 06-05-15 15:24:31, Vladimir Davydov wrote:
On Wed, May 06, 2015 at 01:59:41PM +0200, Michal Hocko wrote:
On Tue 05-05-15 12:45:42, Vladimir Davydov wrote:
Not all kmem allocations should be accounted to memcg. The
On Wed 06-05-15 09:16:22, Johannes Weiner wrote:
On Wed, May 06, 2015 at 01:59:41PM +0200, Michal Hocko wrote:
On Tue 05-05-15 12:45:42, Vladimir Davydov wrote:
Not all kmem allocations should be accounted to memcg. The following
patch gives an example when accounting of a certain type of
On Wed 06-05-15 17:29:51, Vladimir Davydov wrote:
[...]
My point is that MEMCG is the only subsystem of the kernel that tries to
do full memory accounting, and there is no point in introducing another
one, because we already have it.
Then I really do not get why the gfp flag cannot be specific
On Wed, May 06, 2015 at 03:55:20PM +0200, Michal Hocko wrote:
On Wed 06-05-15 16:25:10, Vladimir Davydov wrote:
On Wed, May 06, 2015 at 02:35:41PM +0200, Michal Hocko wrote:
[...]
NOACCOUNT doesn't imply kmem at all so it is not clear who is in charge
of the accounting.
IMO it is a
On Wed, May 06, 2015 at 04:58:14PM +0200, Michal Hocko wrote:
On Tue 05-05-15 12:45:42, Vladimir Davydov wrote:
[...]
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 97a9373e61e8..37c422df2a0f 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -30,6 +30,7 @@
On Wed, May 06, 2015 at 03:46:20PM +0200, Michal Hocko wrote:
On Wed 06-05-15 09:16:22, Johannes Weiner wrote:
On Wed, May 06, 2015 at 01:59:41PM +0200, Michal Hocko wrote:
On Tue 05-05-15 12:45:42, Vladimir Davydov wrote:
Not all kmem allocations should be accounted to memcg. The
On Tue 05-05-15 12:45:42, Vladimir Davydov wrote:
[...]
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 97a9373e61e8..37c422df2a0f 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -30,6 +30,7 @@ struct vm_area_struct;
#define ___GFP_HARDWALL 0x2u
Not all kmem allocations should be accounted to memcg. The following
patch gives an example when accounting of a certain type of allocations
to memcg can effectively result in a memory leak. This patch adds the
__GFP_NOACCOUNT flag which if passed to kmalloc and friends will force
the allocation
Not all kmem allocations should be accounted to memcg. The following
patch gives an example when accounting of a certain type of allocations
to memcg can effectively result in a memory leak. This patch adds the
__GFP_NOACCOUNT flag which if passed to kmalloc and friends will force
the allocation
26 matches
Mail list logo
