From: Frank Mehnert <frank.mehnert@oracle.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: Re: PG_reserved and compound pages
Date: Wed, 06 Apr 2016 17:12:43 +0200 [thread overview]
Message-ID: <3877205.TjDYue2aah@noys2> (raw)
In-Reply-To: <20160406150206.GB24283@dhcp22.suse.cz>
Hi Michal,
On Wednesday 06 April 2016 17:02:06 Michal Hocko wrote:
> [CCing linux-mm mailing list]
>
> On Wed 06-04-16 13:28:37, Frank Mehnert wrote:
> > Hi,
> >
> > Linux 4.5 introduced additional checks to ensure that compound pages are
> > never marked as reserved. In our code we use PG_reserved to ensure that
> > the kernel does never swap out such pages, e.g.
>
> Are you putting your pages on the LRU list? If not how they could get
> swapped out?
No, we do nothing like that. It was my understanding that at least with
older kernels it was possible that pages allocated with alloc_pages()
could be swapped out or otherwise manipulated, I might be wrong. For
instance, it's also necessary that the physical address of the page
is known and that it does never change. I know, there might be problems
with automatic NUMA page migration but that's another story.
> > int i;
> > struct page *pages = alloc_pages(GFP_HIGHUSER | __GFP_COMP, 4);
> > for (i = 0; i < 16; i++)
> >
> > SetPageReserved(&pages[i]);
> >
> > The purpose of setting PG_reserved is to prevent the kernel from swapping
> > this memory out. This worked with older kernel but not with Linux 4.5 as
> > setting PG_reserved to compound pages is not allowed any more.
> >
> > Can somebody explain how we can achieve the same result in accordance to
> > the new Linux 4.5 rules?
Frank
--
Dr.-Ing. Frank Mehnert | Software Development Director, VirtualBox
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | 71384 Weinstadt, Germany
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
--
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: Frank Mehnert <frank.mehnert@oracle.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: Re: PG_reserved and compound pages
Date: Wed, 06 Apr 2016 17:12:43 +0200 [thread overview]
Message-ID: <3877205.TjDYue2aah@noys2> (raw)
In-Reply-To: <20160406150206.GB24283@dhcp22.suse.cz>
Hi Michal,
On Wednesday 06 April 2016 17:02:06 Michal Hocko wrote:
> [CCing linux-mm mailing list]
>
> On Wed 06-04-16 13:28:37, Frank Mehnert wrote:
> > Hi,
> >
> > Linux 4.5 introduced additional checks to ensure that compound pages are
> > never marked as reserved. In our code we use PG_reserved to ensure that
> > the kernel does never swap out such pages, e.g.
>
> Are you putting your pages on the LRU list? If not how they could get
> swapped out?
No, we do nothing like that. It was my understanding that at least with
older kernels it was possible that pages allocated with alloc_pages()
could be swapped out or otherwise manipulated, I might be wrong. For
instance, it's also necessary that the physical address of the page
is known and that it does never change. I know, there might be problems
with automatic NUMA page migration but that's another story.
> > int i;
> > struct page *pages = alloc_pages(GFP_HIGHUSER | __GFP_COMP, 4);
> > for (i = 0; i < 16; i++)
> >
> > SetPageReserved(&pages[i]);
> >
> > The purpose of setting PG_reserved is to prevent the kernel from swapping
> > this memory out. This worked with older kernel but not with Linux 4.5 as
> > setting PG_reserved to compound pages is not allowed any more.
> >
> > Can somebody explain how we can achieve the same result in accordance to
> > the new Linux 4.5 rules?
Frank
--
Dr.-Ing. Frank Mehnert | Software Development Director, VirtualBox
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | 71384 Weinstadt, Germany
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
next prev parent reply other threads:[~2016-04-06 15:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-06 11:28 PG_reserved and compound pages Frank Mehnert
2016-04-06 15:02 ` Michal Hocko
2016-04-06 15:02 ` Michal Hocko
2016-04-06 15:12 ` Frank Mehnert [this message]
2016-04-06 15:12 ` Frank Mehnert
2016-04-06 15:33 ` Michal Hocko
2016-04-06 15:33 ` Michal Hocko
2016-04-07 13:45 ` Frank Mehnert
2016-04-07 13:45 ` Frank Mehnert
2016-04-07 15:22 ` Michal Hocko
2016-04-07 15:22 ` Michal Hocko
2016-04-19 10:34 ` Frank Mehnert
2016-04-19 10:34 ` Frank Mehnert
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=3877205.TjDYue2aah@noys2 \
--to=frank.mehnert@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
/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.