On Thu, May 30, 2013 at 12:43:44PM -0500, Seth Jennings wrote:
> On Wed, May 29, 2013 at 02:29:04PM -0700, Andrew Morton wrote:
> > On Wed, 29 May 2013 14:09:02 -0700 (PDT) Dan Magenheimer
> > wrote:
> >
> > > > memory_failure() is merely an example of a general problem: code which
> > > > reads
Hi Seth,
On 05/31/2013 05:20 AM, Seth Jennings wrote:
> Andrew, Mel,
>
> This struct page stuffing is taking a lot of time to work out and _might_ be
> fraught with peril when memmap peekers are considered.
>
> What do you think about just storing the zbud page metadata inline in the
> memory pa
Andrew, Mel,
This struct page stuffing is taking a lot of time to work out and _might_ be
fraught with peril when memmap peekers are considered.
What do you think about just storing the zbud page metadata inline in the
memory page in the first zbud page chunk?
Mel, this kinda hurts you plans for
On Wed, May 29, 2013 at 02:29:04PM -0700, Andrew Morton wrote:
> On Wed, 29 May 2013 14:09:02 -0700 (PDT) Dan Magenheimer
> wrote:
>
> > > memory_failure() is merely an example of a general problem: code which
> > > reads from the memmap[] array and expects its elements to be of type
> > > `stru
On Wed, 29 May 2013 14:09:02 -0700 (PDT) Dan Magenheimer
wrote:
> > memory_failure() is merely an example of a general problem: code which
> > reads from the memmap[] array and expects its elements to be of type
> > `struct page'. Other examples might be memory hotplugging, memory leak
> > chec
> From: Andrew Morton [mailto:a...@linux-foundation.org]
> Subject: Re: [PATCHv12 2/4] zbud: add to mm/
>
> On Wed, 29 May 2013 15:42:36 -0500 Seth Jennings
> wrote:
>
> > > > > I worry about any code which independently looks at the pageframe
> > >
On Wed, 29 May 2013 15:42:36 -0500 Seth Jennings
wrote:
> > > > I worry about any code which independently looks at the pageframe
> > > > tables and expects to find page struts there. One example is probably
> > > > memory_failure() but there are probably others.
> >
> > ^^ this, please. It c
On Wed, May 29, 2013 at 11:34:34AM -0700, Andrew Morton wrote:
> > > > + if (size <= 0 || gfp & __GFP_HIGHMEM)
> > > > + return -EINVAL;
> > > > + if (size > PAGE_SIZE)
> > > > + return -E2BIG;
> > >
> > > Means "Argument list too long" and isn't appropriate
On Wed, May 29, 2013 at 11:34:34AM -0700, Andrew Morton wrote:
> On Wed, 29 May 2013 10:45:00 -0500 Seth Jennings
> wrote:
>
> > > > +struct zbud_page {
> > > > + union {
> > > > + struct page page;
> > > > + struct {
> > > > + unsigned lon
On Wed, 29 May 2013 10:45:00 -0500 Seth Jennings
wrote:
> > > +struct zbud_page {
> > > + union {
> > > + struct page page;
> > > + struct {
> > > + unsigned long donotuse;
> > > + u16 first_chunks;
> > > + u16 last_chunks;
> > > +
On Tue, May 28, 2013 at 02:59:11PM -0700, Andrew Morton wrote:
> On Mon, 20 May 2013 11:26:06 -0500 Seth Jennings
> wrote:
>
> > zbud is an special purpose allocator for storing compressed pages. It is
> > designed to store up to two compressed pages per physical page. While this
> > design lim
On Mon, 20 May 2013 11:26:06 -0500 Seth Jennings
wrote:
> zbud is an special purpose allocator for storing compressed pages. It is
> designed to store up to two compressed pages per physical page. While this
> design limits storage density, it has simple and deterministic reclaim
> properties t
On 05/21/2013 12:26 AM, Seth Jennings wrote:
> zbud is an special purpose allocator for storing compressed pages. It is
> designed to store up to two compressed pages per physical page. While this
> design limits storage density, it has simple and deterministic reclaim
> properties that make it
zbud is an special purpose allocator for storing compressed pages. It is
designed to store up to two compressed pages per physical page. While this
design limits storage density, it has simple and deterministic reclaim
properties that make it preferable to a higher density approach when reclaim
wi
14 matches
Mail list logo
