All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Pekka Enberg <penberg@kernel.org>,
	Christoph Lameter <cl@linux.com>, Joonsoo Kim <js1304@gmail.com>,
	David Rientjes <rientjes@google.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Wanpeng Li <liwanp@linux.vnet.ibm.com>
Subject: Re: [PATCH v2 00/15] slab: overload struct slab over struct page to reduce memory usage
Date: Sat, 19 Oct 2013 15:39:34 -0700	[thread overview]
Message-ID: <8738nwvqah.fsf@tassilo.jf.intel.com> (raw)
In-Reply-To: <20131016133457.60fa71f893cd2962d8ec6ff3@linux-foundation.org> (Andrew Morton's message of "Wed, 16 Oct 2013 13:34:57 -0700")

Andrew Morton <akpm@linux-foundation.org> writes:
>
> One example is mm/memory-failure.c:memory_failure().  It starts with a
> raw pfn, uses that to get at the `struct page', then starts playing
> around with it.  Will that code still work correctly when some of the
> page's fields have been overlayed with slab-specific contents?

As long as PageSlab() works correctly memory_failure should be happy.

>
> This issue hasn't been well thought through.  Given a random struct
> page, there isn't any protocol to determine what it actually *is*. 
> It's a plain old variant record, but it lacks the agreed-upon tag field
> which tells users which variant is currently in use.

PageSlab() should work for this right?

For the generic case it may not though.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Andi Kleen <andi@firstfloor.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Pekka Enberg <penberg@kernel.org>,
	Christoph Lameter <cl@linux.com>, Joonsoo Kim <js1304@gmail.com>,
	David Rientjes <rientjes@google.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Wanpeng Li <liwanp@linux.vnet.ibm.com>
Subject: Re: [PATCH v2 00/15] slab: overload struct slab over struct page to reduce memory usage
Date: Sat, 19 Oct 2013 15:39:34 -0700	[thread overview]
Message-ID: <8738nwvqah.fsf@tassilo.jf.intel.com> (raw)
In-Reply-To: <20131016133457.60fa71f893cd2962d8ec6ff3@linux-foundation.org> (Andrew Morton's message of "Wed, 16 Oct 2013 13:34:57 -0700")

Andrew Morton <akpm@linux-foundation.org> writes:
>
> One example is mm/memory-failure.c:memory_failure().  It starts with a
> raw pfn, uses that to get at the `struct page', then starts playing
> around with it.  Will that code still work correctly when some of the
> page's fields have been overlayed with slab-specific contents?

As long as PageSlab() works correctly memory_failure should be happy.

>
> This issue hasn't been well thought through.  Given a random struct
> page, there isn't any protocol to determine what it actually *is*. 
> It's a plain old variant record, but it lacks the agreed-upon tag field
> which tells users which variant is currently in use.

PageSlab() should work for this right?

For the generic case it may not though.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only

  parent reply	other threads:[~2013-10-19 22:39 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-16  8:43 [PATCH v2 00/15] slab: overload struct slab over struct page to reduce memory usage Joonsoo Kim
2013-10-16  8:43 ` Joonsoo Kim
2013-10-16  8:43 ` [PATCH v2 01/15] slab: correct pfmemalloc check Joonsoo Kim
2013-10-16  8:43   ` Joonsoo Kim
2013-10-16 15:27   ` Christoph Lameter
2013-10-16 15:27     ` Christoph Lameter
2013-10-17  5:27     ` Joonsoo Kim
2013-10-17  5:27       ` Joonsoo Kim
2013-10-16  8:43 ` [PATCH v2 02/15] slab: change return type of kmem_getpages() to struct page Joonsoo Kim
2013-10-16  8:43   ` Joonsoo Kim
2013-10-16  8:44 ` [PATCH v2 03/15] slab: remove colouroff in struct slab Joonsoo Kim
2013-10-16  8:44   ` Joonsoo Kim
2013-10-16  8:44 ` [PATCH v2 04/15] slab: remove nodeid " Joonsoo Kim
2013-10-16  8:44   ` Joonsoo Kim
2013-10-17 19:05   ` Christoph Lameter
2013-10-17 19:05     ` Christoph Lameter
2013-10-16  8:44 ` [PATCH v2 05/15] slab: remove cachep in struct slab_rcu Joonsoo Kim
2013-10-16  8:44   ` Joonsoo Kim
2013-10-16  8:44 ` [PATCH v2 06/15] slab: overloading the RCU head over the LRU for RCU free Joonsoo Kim
2013-10-16  8:44   ` Joonsoo Kim
2013-10-16  8:44 ` [PATCH v2 07/15] slab: use well-defined macro, virt_to_slab() Joonsoo Kim
2013-10-16  8:44   ` Joonsoo Kim
2013-10-16  8:44 ` [PATCH v2 08/15] slab: use __GFP_COMP flag for allocating slab pages Joonsoo Kim
2013-10-16  8:44   ` Joonsoo Kim
2013-10-17 19:08   ` Christoph Lameter
2013-10-17 19:08     ` Christoph Lameter
2013-10-18 15:13     ` JoonSoo Kim
2013-10-18 15:13       ` JoonSoo Kim
2013-10-16  8:44 ` [PATCH v2 09/15] slab: change the management method of free objects of the slab Joonsoo Kim
2013-10-16  8:44   ` Joonsoo Kim
2013-10-16  8:44 ` [PATCH v2 10/15] slab: remove kmem_bufctl_t Joonsoo Kim
2013-10-16  8:44   ` Joonsoo Kim
2013-10-16  8:44 ` [PATCH v2 11/15] slab: remove SLAB_LIMIT Joonsoo Kim
2013-10-16  8:44   ` Joonsoo Kim
2013-10-17 19:09   ` Christoph Lameter
2013-10-17 19:09     ` Christoph Lameter
2013-10-16  8:44 ` [PATCH v2 12/15] slab: replace free and inuse in struct slab with newly introduced active Joonsoo Kim
2013-10-16  8:44   ` Joonsoo Kim
2013-10-16  8:44 ` [PATCH v2 13/15] slab: use struct page for slab management Joonsoo Kim
2013-10-16  8:44   ` Joonsoo Kim
2013-10-17 19:13   ` Christoph Lameter
2013-10-17 19:13     ` Christoph Lameter
2013-10-18 15:05     ` JoonSoo Kim
2013-10-18 15:05       ` JoonSoo Kim
2013-10-20 18:05       ` Christoph Lameter
2013-10-20 18:05         ` Christoph Lameter
2013-10-30  8:28   ` Joonsoo Kim
2013-10-30  8:28     ` Joonsoo Kim
2013-10-30  8:42     ` Pekka Enberg
2013-10-30  8:42       ` Pekka Enberg
2013-10-30 10:06       ` Joonsoo Kim
2013-10-30 10:06         ` Joonsoo Kim
2013-10-16  8:44 ` [PATCH v2 14/15] slab: remove useless statement for checking pfmemalloc Joonsoo Kim
2013-10-16  8:44   ` Joonsoo Kim
2013-10-16  8:44 ` [PATCH v2 15/15] slab: rename slab_bufctl to slab_freelist Joonsoo Kim
2013-10-16  8:44   ` Joonsoo Kim
2013-10-16 20:34 ` [PATCH v2 00/15] slab: overload struct slab over struct page to reduce memory usage Andrew Morton
2013-10-16 20:34   ` Andrew Morton
2013-10-17  6:01   ` Joonsoo Kim
2013-10-17  6:01     ` Joonsoo Kim
2013-10-17  7:20   ` Pekka Enberg
2013-10-17  7:20     ` Pekka Enberg
2013-10-17 18:02     ` Christoph Lameter
2013-10-17 18:02       ` Christoph Lameter
2013-10-17 19:15   ` Christoph Lameter
2013-10-17 19:15     ` Christoph Lameter
2013-10-19 22:39   ` Andi Kleen [this message]
2013-10-19 22:39     ` Andi Kleen
2013-10-19 22:41 ` Andi Kleen
2013-10-19 22:41   ` Andi Kleen
2013-10-30 10:04 ` [PATCH v2 16/15] slab: fix to calm down kmemleak warning Joonsoo Kim
2013-10-30 10:04   ` Joonsoo Kim
2013-10-30 10:04   ` [PATCH v2 17/15] slab: replace non-existing 'struct freelist *' with 'void *' Joonsoo Kim
2013-10-30 10:04     ` Joonsoo Kim
2013-11-01 19:09     ` Christoph Lameter
2013-11-01 19:09       ` Christoph Lameter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8738nwvqah.fsf@tassilo.jf.intel.com \
    --to=andi@firstfloor.org \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=js1304@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liwanp@linux.vnet.ibm.com \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.