On Thu, Aug 16, 2012 at 07:20:15PM +0100, Michal Hocko wrote:
> On Thu 16-08-12 17:09:54, Will Deacon wrote:
> > +static inline void arch_clear_hugepage_flags(struct page *page)
> > +{
> > + flush_dcache_page(page);
> > +}
> > +
>
> Why do we need the hook for ia64? hugetlb_no_page calls
On Thu 16-08-12 17:09:54, Will Deacon wrote:
> On Wed, Aug 08, 2012 at 05:26:07PM +0100, Michal Hocko wrote:
[...]
> diff --git a/arch/ia64/include/asm/hugetlb.h b/arch/ia64/include/asm/hugetlb.h
> index da55c63..2adaa60 100644
> --- a/arch/ia64/include/asm/hugetlb.h
> +++
On Thu, Aug 16, 2012 at 07:06:14PM +0100, Michal Hocko wrote:
> On Thu 16-08-12 18:34:59, Will Deacon wrote:
> > I just did it that way to match the flag clearing for normal pages. I can
> > move it into dequeue if you think it's worthwhile but in the worst case it
> > just adds a clear_bit call,
On Thu 16-08-12 18:34:59, Will Deacon wrote:
> On Thu, Aug 16, 2012 at 06:25:27PM +0100, Michal Hocko wrote:
> > On Thu 16-08-12 17:09:54, Will Deacon wrote:
> > > On Wed, Aug 08, 2012 at 05:26:07PM +0100, Michal Hocko wrote:
> > > > I guess the cleanest way is to hook into dequeue_huge_page_node
On Thu, Aug 16, 2012 at 06:25:27PM +0100, Michal Hocko wrote:
> On Thu 16-08-12 17:09:54, Will Deacon wrote:
> > On Wed, Aug 08, 2012 at 05:26:07PM +0100, Michal Hocko wrote:
> > > I guess the cleanest way is to hook into dequeue_huge_page_node and add
> > > something like
On Thu 16-08-12 17:09:54, Will Deacon wrote:
> On Wed, Aug 08, 2012 at 05:26:07PM +0100, Michal Hocko wrote:
> > I guess the cleanest way is to hook into dequeue_huge_page_node and add
> > something like arch_clear_hugepage_flags.
>
> I hooked into enqueue_huge_page instead, but how about
On Wed, Aug 08, 2012 at 05:26:07PM +0100, Michal Hocko wrote:
> I guess the cleanest way is to hook into dequeue_huge_page_node and add
> something like arch_clear_hugepage_flags.
I hooked into enqueue_huge_page instead, but how about something like this?:
Will
--- >8
>From
On Wed, Aug 08, 2012 at 05:26:07PM +0100, Michal Hocko wrote:
I guess the cleanest way is to hook into dequeue_huge_page_node and add
something like arch_clear_hugepage_flags.
I hooked into enqueue_huge_page instead, but how about something like this?:
Will
--- 8
From
On Thu 16-08-12 17:09:54, Will Deacon wrote:
On Wed, Aug 08, 2012 at 05:26:07PM +0100, Michal Hocko wrote:
I guess the cleanest way is to hook into dequeue_huge_page_node and add
something like arch_clear_hugepage_flags.
I hooked into enqueue_huge_page instead, but how about something like
On Thu, Aug 16, 2012 at 06:25:27PM +0100, Michal Hocko wrote:
On Thu 16-08-12 17:09:54, Will Deacon wrote:
On Wed, Aug 08, 2012 at 05:26:07PM +0100, Michal Hocko wrote:
I guess the cleanest way is to hook into dequeue_huge_page_node and add
something like arch_clear_hugepage_flags.
I
On Thu 16-08-12 18:34:59, Will Deacon wrote:
On Thu, Aug 16, 2012 at 06:25:27PM +0100, Michal Hocko wrote:
On Thu 16-08-12 17:09:54, Will Deacon wrote:
On Wed, Aug 08, 2012 at 05:26:07PM +0100, Michal Hocko wrote:
I guess the cleanest way is to hook into dequeue_huge_page_node and add
On Thu, Aug 16, 2012 at 07:06:14PM +0100, Michal Hocko wrote:
On Thu 16-08-12 18:34:59, Will Deacon wrote:
I just did it that way to match the flag clearing for normal pages. I can
move it into dequeue if you think it's worthwhile but in the worst case it
just adds a clear_bit call, so I
On Thu 16-08-12 17:09:54, Will Deacon wrote:
On Wed, Aug 08, 2012 at 05:26:07PM +0100, Michal Hocko wrote:
[...]
diff --git a/arch/ia64/include/asm/hugetlb.h b/arch/ia64/include/asm/hugetlb.h
index da55c63..2adaa60 100644
--- a/arch/ia64/include/asm/hugetlb.h
+++
On Thu, Aug 16, 2012 at 07:20:15PM +0100, Michal Hocko wrote:
On Thu 16-08-12 17:09:54, Will Deacon wrote:
+static inline void arch_clear_hugepage_flags(struct page *page)
+{
+ flush_dcache_page(page);
+}
+
Why do we need the hook for ia64? hugetlb_no_page calls clear_huge_page
On Tue 07-08-12 17:03:37, Will Deacon wrote:
>
>
> On Thu, Jul 12, 2012 at 12:57:08PM +0100, Michal Hocko wrote:
> > On Thu 12-07-12 12:26:45, Will Deacon wrote:
> > > Well, the comment in linux/page-flags.h does state that:
> > >
> > > * PG_arch_1 is an architecture specific page state bit.
On Tue 07-08-12 17:03:37, Will Deacon wrote:
resurrecting this thread
On Thu, Jul 12, 2012 at 12:57:08PM +0100, Michal Hocko wrote:
On Thu 12-07-12 12:26:45, Will Deacon wrote:
Well, the comment in linux/page-flags.h does state that:
* PG_arch_1 is an architecture specific page
On Thu, Jul 12, 2012 at 12:57:08PM +0100, Michal Hocko wrote:
> On Thu 12-07-12 12:26:45, Will Deacon wrote:
> > Well, the comment in linux/page-flags.h does state that:
> >
> > * PG_arch_1 is an architecture specific page state bit. The generic code
> > * guarantees that this bit is cleared
resurrecting this thread
On Thu, Jul 12, 2012 at 12:57:08PM +0100, Michal Hocko wrote:
On Thu 12-07-12 12:26:45, Will Deacon wrote:
Well, the comment in linux/page-flags.h does state that:
* PG_arch_1 is an architecture specific page state bit. The generic code
* guarantees that this
On Thu 12-07-12 12:26:45, Will Deacon wrote:
> On Thu, Jul 12, 2012 at 12:16:59PM +0100, Michal Hocko wrote:
> > On Wed 11-07-12 18:48:02, Will Deacon wrote:
> > > Just to confirm, the following quick hack at least results in the correct
> > > flushing for me (on ARM):
> > >
> > >
> > > diff
On Thu, Jul 12, 2012 at 12:16:59PM +0100, Michal Hocko wrote:
> On Wed 11-07-12 18:48:02, Will Deacon wrote:
> > Just to confirm, the following quick hack at least results in the correct
> > flushing for me (on ARM):
> >
> >
> > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > index e198831..7a7c9d3
On Thu, 2012-07-12 at 13:16 +0200, Michal Hocko wrote:
> On Wed 11-07-12 18:48:02, Will Deacon wrote:
> > On Tue, Jul 10, 2012 at 11:42:34AM +0100, Will Deacon wrote:
> > > On Tue, Jul 10, 2012 at 10:45:13AM +0100, Will Deacon wrote:
> > > > On Tue, Jul 10, 2012 at 12:57:14AM +0100, Hugh Dickins
On Wed 11-07-12 18:48:02, Will Deacon wrote:
> On Tue, Jul 10, 2012 at 11:42:34AM +0100, Will Deacon wrote:
> > On Tue, Jul 10, 2012 at 10:45:13AM +0100, Will Deacon wrote:
> > > On Tue, Jul 10, 2012 at 12:57:14AM +0100, Hugh Dickins wrote:
> > > > If I start to grep the architectures for
On Wed 11-07-12 18:48:02, Will Deacon wrote:
On Tue, Jul 10, 2012 at 11:42:34AM +0100, Will Deacon wrote:
On Tue, Jul 10, 2012 at 10:45:13AM +0100, Will Deacon wrote:
On Tue, Jul 10, 2012 at 12:57:14AM +0100, Hugh Dickins wrote:
If I start to grep the architectures for non-empty
On Thu, 2012-07-12 at 13:16 +0200, Michal Hocko wrote:
On Wed 11-07-12 18:48:02, Will Deacon wrote:
On Tue, Jul 10, 2012 at 11:42:34AM +0100, Will Deacon wrote:
On Tue, Jul 10, 2012 at 10:45:13AM +0100, Will Deacon wrote:
On Tue, Jul 10, 2012 at 12:57:14AM +0100, Hugh Dickins wrote:
On Thu, Jul 12, 2012 at 12:16:59PM +0100, Michal Hocko wrote:
On Wed 11-07-12 18:48:02, Will Deacon wrote:
Just to confirm, the following quick hack at least results in the correct
flushing for me (on ARM):
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index e198831..7a7c9d3 100644
---
On Thu 12-07-12 12:26:45, Will Deacon wrote:
On Thu, Jul 12, 2012 at 12:16:59PM +0100, Michal Hocko wrote:
On Wed 11-07-12 18:48:02, Will Deacon wrote:
Just to confirm, the following quick hack at least results in the correct
flushing for me (on ARM):
diff --git a/mm/hugetlb.c
On Tue, Jul 10, 2012 at 11:42:34AM +0100, Will Deacon wrote:
> On Tue, Jul 10, 2012 at 10:45:13AM +0100, Will Deacon wrote:
> > On Tue, Jul 10, 2012 at 12:57:14AM +0100, Hugh Dickins wrote:
> > > If I start to grep the architectures for non-empty flush_dcache_page(),
> > > I soon find things in
On Tue, Jul 10, 2012 at 11:42:34AM +0100, Will Deacon wrote:
On Tue, Jul 10, 2012 at 10:45:13AM +0100, Will Deacon wrote:
On Tue, Jul 10, 2012 at 12:57:14AM +0100, Hugh Dickins wrote:
If I start to grep the architectures for non-empty flush_dcache_page(),
I soon find things in arch/arm
On Tue, Jul 10, 2012 at 10:45:13AM +0100, Will Deacon wrote:
> On Tue, Jul 10, 2012 at 12:57:14AM +0100, Hugh Dickins wrote:
> > If I start to grep the architectures for non-empty flush_dcache_page(),
> > I soon find things in arch/arm such as v4_mc_copy_user_highpage() doing
> > if
Hi Hugh,
Cheers for looking at this.
On Tue, Jul 10, 2012 at 12:57:14AM +0100, Hugh Dickins wrote:
> On Mon, 9 Jul 2012, Will Deacon wrote:
> > On Mon, Jul 09, 2012 at 01:25:23PM +0100, Michal Hocko wrote:
> > > On Wed 04-07-12 15:32:56, Will Deacon wrote:
> > > > diff --git a/mm/hugetlb.c
Hi Hugh,
Cheers for looking at this.
On Tue, Jul 10, 2012 at 12:57:14AM +0100, Hugh Dickins wrote:
On Mon, 9 Jul 2012, Will Deacon wrote:
On Mon, Jul 09, 2012 at 01:25:23PM +0100, Michal Hocko wrote:
On Wed 04-07-12 15:32:56, Will Deacon wrote:
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
On Tue, Jul 10, 2012 at 10:45:13AM +0100, Will Deacon wrote:
On Tue, Jul 10, 2012 at 12:57:14AM +0100, Hugh Dickins wrote:
If I start to grep the architectures for non-empty flush_dcache_page(),
I soon find things in arch/arm such as v4_mc_copy_user_highpage() doing
if
On Mon, 9 Jul 2012, Will Deacon wrote:
> On Mon, Jul 09, 2012 at 01:25:23PM +0100, Michal Hocko wrote:
> > On Wed 04-07-12 15:32:56, Will Deacon wrote:
> > > When allocating and returning clear huge pages to userspace as a
> > > response to a fault, we may zero and return a mapping to a previously
On Mon, Jul 09, 2012 at 01:25:23PM +0100, Michal Hocko wrote:
> On Wed 04-07-12 15:32:56, Will Deacon wrote:
> > When allocating and returning clear huge pages to userspace as a
> > response to a fault, we may zero and return a mapping to a previously
> > dirtied physical region (for example, it
On Wed 04-07-12 15:32:56, Will Deacon wrote:
> When allocating and returning clear huge pages to userspace as a
> response to a fault, we may zero and return a mapping to a previously
> dirtied physical region (for example, it may have been written by
> a private mapping which was freed as a
On Wed 04-07-12 15:32:56, Will Deacon wrote:
When allocating and returning clear huge pages to userspace as a
response to a fault, we may zero and return a mapping to a previously
dirtied physical region (for example, it may have been written by
a private mapping which was freed as a result of
On Mon, Jul 09, 2012 at 01:25:23PM +0100, Michal Hocko wrote:
On Wed 04-07-12 15:32:56, Will Deacon wrote:
When allocating and returning clear huge pages to userspace as a
response to a fault, we may zero and return a mapping to a previously
dirtied physical region (for example, it may have
On Mon, 9 Jul 2012, Will Deacon wrote:
On Mon, Jul 09, 2012 at 01:25:23PM +0100, Michal Hocko wrote:
On Wed 04-07-12 15:32:56, Will Deacon wrote:
When allocating and returning clear huge pages to userspace as a
response to a fault, we may zero and return a mapping to a previously
38 matches
Mail list logo
