On Mon, Jun 02, 2014 at 06:04:02PM +0200, David Herrmann wrote:
> Correct, the problem is not accounting for pinned-pages, but waiting
> for them to get released. Furthermore, Peter's patches make VM_PINNED
> an optional feature, so we'd still miss all the short-term GUP users.
> Sadly, that means
On Mon, Jun 02, 2014 at 06:04:02PM +0200, David Herrmann wrote:
Correct, the problem is not accounting for pinned-pages, but waiting
for them to get released. Furthermore, Peter's patches make VM_PINNED
an optional feature, so we'd still miss all the short-term GUP users.
Sadly, that means we
Hi
On Mon, Jun 2, 2014 at 11:14 AM, Jan Kara wrote:
> On Mon 02-06-14 13:42:59, Minchan Kim wrote:
>> On Mon, May 19, 2014 at 01:44:25PM +0200, David Herrmann wrote:
>> > I tried doing the page-replacement in the last 4 days, but honestly,
>> > it's far more complex than I thought. So if no-one
On Mon 02-06-14 13:42:59, Minchan Kim wrote:
> Hello,
>
> On Mon, May 19, 2014 at 01:44:25PM +0200, David Herrmann wrote:
> > Hi
> >
> > On Thu, May 15, 2014 at 12:35 AM, Hugh Dickins wrote:
> > > The aspect which really worries me is this: the maintenance burden.
> > > This approach would add
On Mon 02-06-14 13:42:59, Minchan Kim wrote:
Hello,
On Mon, May 19, 2014 at 01:44:25PM +0200, David Herrmann wrote:
Hi
On Thu, May 15, 2014 at 12:35 AM, Hugh Dickins hu...@google.com wrote:
The aspect which really worries me is this: the maintenance burden.
This approach would add
Hi
On Mon, Jun 2, 2014 at 11:14 AM, Jan Kara j...@suse.cz wrote:
On Mon 02-06-14 13:42:59, Minchan Kim wrote:
On Mon, May 19, 2014 at 01:44:25PM +0200, David Herrmann wrote:
I tried doing the page-replacement in the last 4 days, but honestly,
it's far more complex than I thought. So if
Hello,
On Mon, May 19, 2014 at 01:44:25PM +0200, David Herrmann wrote:
> Hi
>
> On Thu, May 15, 2014 at 12:35 AM, Hugh Dickins wrote:
> > The aspect which really worries me is this: the maintenance burden.
> > This approach would add some peculiar new code, introducing a rare
> > special case:
Hello,
On Mon, May 19, 2014 at 01:44:25PM +0200, David Herrmann wrote:
Hi
On Thu, May 15, 2014 at 12:35 AM, Hugh Dickins hu...@google.com wrote:
The aspect which really worries me is this: the maintenance burden.
This approach would add some peculiar new code, introducing a rare
special
On Mon, 26 May 2014, David Herrmann wrote:
>
> (CC migrate.c committers)
>
> On Tue, May 20, 2014 at 12:11 AM, Hugh Dickins wrote:
> > On Mon, 19 May 2014, Jan Kara wrote:
> >> On Mon 19-05-14 13:44:25, David Herrmann wrote:
> >> > On Thu, May 15, 2014 at 12:35 AM, Hugh Dickins wrote:
> >> > >
On Mon, 26 May 2014, David Herrmann wrote:
(CC migrate.c committers)
On Tue, May 20, 2014 at 12:11 AM, Hugh Dickins hu...@google.com wrote:
On Mon, 19 May 2014, Jan Kara wrote:
On Mon 19-05-14 13:44:25, David Herrmann wrote:
On Thu, May 15, 2014 at 12:35 AM, Hugh Dickins
Hi
(CC migrate.c committers)
On Tue, May 20, 2014 at 12:11 AM, Hugh Dickins wrote:
> On Mon, 19 May 2014, Jan Kara wrote:
>> On Mon 19-05-14 13:44:25, David Herrmann wrote:
>> > On Thu, May 15, 2014 at 12:35 AM, Hugh Dickins wrote:
>> > > The aspect which really worries me is this: the
Hi
(CC migrate.c committers)
On Tue, May 20, 2014 at 12:11 AM, Hugh Dickins hu...@google.com wrote:
On Mon, 19 May 2014, Jan Kara wrote:
On Mon 19-05-14 13:44:25, David Herrmann wrote:
On Thu, May 15, 2014 at 12:35 AM, Hugh Dickins hu...@google.com wrote:
The aspect which really worries
On Mon, 19 May 2014, Jan Kara wrote:
> On Mon 19-05-14 13:44:25, David Herrmann wrote:
> > On Thu, May 15, 2014 at 12:35 AM, Hugh Dickins wrote:
> > > The aspect which really worries me is this: the maintenance burden.
> > > This approach would add some peculiar new code, introducing a rare
> > >
On Mon 19-05-14 13:44:25, David Herrmann wrote:
> Hi
>
> On Thu, May 15, 2014 at 12:35 AM, Hugh Dickins wrote:
> > The aspect which really worries me is this: the maintenance burden.
> > This approach would add some peculiar new code, introducing a rare
> > special case: which we might get right
Hi
On Thu, May 15, 2014 at 12:35 AM, Hugh Dickins wrote:
> The aspect which really worries me is this: the maintenance burden.
> This approach would add some peculiar new code, introducing a rare
> special case: which we might get right today, but will very easily
> forget tomorrow when making
On Mon, 19 May 2014, Jan Kara wrote:
On Mon 19-05-14 13:44:25, David Herrmann wrote:
On Thu, May 15, 2014 at 12:35 AM, Hugh Dickins hu...@google.com wrote:
The aspect which really worries me is this: the maintenance burden.
This approach would add some peculiar new code, introducing a
Hi
On Thu, May 15, 2014 at 12:35 AM, Hugh Dickins hu...@google.com wrote:
The aspect which really worries me is this: the maintenance burden.
This approach would add some peculiar new code, introducing a rare
special case: which we might get right today, but will very easily
forget tomorrow
On Mon 19-05-14 13:44:25, David Herrmann wrote:
Hi
On Thu, May 15, 2014 at 12:35 AM, Hugh Dickins hu...@google.com wrote:
The aspect which really worries me is this: the maintenance burden.
This approach would add some peculiar new code, introducing a rare
special case: which we might
On Wed, 14 May 2014, Tony Battersby wrote:
> Hugh Dickins wrote:
> > Checking page counts in a GB file prior to sealing does not appeal at
> > all: we'd be lucky ever to find them all accounted for.
>
> Here is a refinement of that idea: during a seal operation, iterate over
> all the pages in
Hugh Dickins wrote:
> Checking page counts in a GB file prior to sealing does not appeal at
> all: we'd be lucky ever to find them all accounted for.
Here is a refinement of that idea: during a seal operation, iterate over
all the pages in the file and check their refcounts. On any page that
has
Hugh Dickins wrote:
Checking page counts in a GB file prior to sealing does not appeal at
all: we'd be lucky ever to find them all accounted for.
Here is a refinement of that idea: during a seal operation, iterate over
all the pages in the file and check their refcounts. On any page that
has
On Wed, 14 May 2014, Tony Battersby wrote:
Hugh Dickins wrote:
Checking page counts in a GB file prior to sealing does not appeal at
all: we'd be lucky ever to find them all accounted for.
Here is a refinement of that idea: during a seal operation, iterate over
all the pages in the file
On Tue, 15 Apr 2014, David Herrmann wrote:
>
> This is v2 of the File-Sealing and memfd_create() patches. You can find v1
> with
> a longer introduction at gmane:
> http://thread.gmane.org/gmane.comp.video.dri.devel/102241
> An LWN article about memfd+sealing is available, too:
>
On Tue, 15 Apr 2014, David Herrmann wrote:
This is v2 of the File-Sealing and memfd_create() patches. You can find v1
with
a longer introduction at gmane:
http://thread.gmane.org/gmane.comp.video.dri.devel/102241
An LWN article about memfd+sealing is available, too:
Hi
This is v2 of the File-Sealing and memfd_create() patches. You can find v1 with
a longer introduction at gmane:
http://thread.gmane.org/gmane.comp.video.dri.devel/102241
An LWN article about memfd+sealing is available, too:
https://lwn.net/Articles/593918/
Shortlog of changes since v1:
-
Hi
This is v2 of the File-Sealing and memfd_create() patches. You can find v1 with
a longer introduction at gmane:
http://thread.gmane.org/gmane.comp.video.dri.devel/102241
An LWN article about memfd+sealing is available, too:
https://lwn.net/Articles/593918/
Shortlog of changes since v1:
-
26 matches
Mail list logo
