Re: [13/17] Virtual compound page freeing in interrupt context
On Fri, 28 Sep 2007 10:35:44 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Fri, 28 Sep 2007, KAMEZAWA Hiroyuki wrote:
>
> > On Tue, 25 Sep 2007 16:42:17 -0700
> > Christoph Lameter <[EMAIL PROTECTED]> wrote:
> >
> > > +static noinline void vcompound_free(void *addr)
> > > +{
> > > + if (in_interrupt()) {
> >
> > Should be (in_interrupt() || irqs_disabled()) ?
>
> Maybe only irqs_disabled()?
>
Ah,.. maybe.
-Kame
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [13/17] Virtual compound page freeing in interrupt context
On Fri, 28 Sep 2007, KAMEZAWA Hiroyuki wrote:
> On Tue, 25 Sep 2007 16:42:17 -0700
> Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> > +static noinline void vcompound_free(void *addr)
> > +{
> > + if (in_interrupt()) {
>
> Should be (in_interrupt() || irqs_disabled()) ?
Maybe only irqs_disabled()?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [13/17] Virtual compound page freeing in interrupt context
On Fri, 28 Sep 2007, KAMEZAWA Hiroyuki wrote:
On Tue, 25 Sep 2007 16:42:17 -0700
Christoph Lameter [EMAIL PROTECTED] wrote:
+static noinline void vcompound_free(void *addr)
+{
+ if (in_interrupt()) {
Should be (in_interrupt() || irqs_disabled()) ?
Maybe only irqs_disabled()?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [13/17] Virtual compound page freeing in interrupt context
On Fri, 28 Sep 2007 10:35:44 -0700 (PDT)
Christoph Lameter [EMAIL PROTECTED] wrote:
On Fri, 28 Sep 2007, KAMEZAWA Hiroyuki wrote:
On Tue, 25 Sep 2007 16:42:17 -0700
Christoph Lameter [EMAIL PROTECTED] wrote:
+static noinline void vcompound_free(void *addr)
+{
+ if (in_interrupt()) {
Should be (in_interrupt() || irqs_disabled()) ?
Maybe only irqs_disabled()?
Ah,.. maybe.
-Kame
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [13/17] Virtual compound page freeing in interrupt context
On Tue, 25 Sep 2007 16:42:17 -0700
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> +static noinline void vcompound_free(void *addr)
> +{
> + if (in_interrupt()) {
Should be (in_interrupt() || irqs_disabled()) ?
Regards,
-Kame
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [13/17] Virtual compound page freeing in interrupt context
On Tue, 25 Sep 2007 16:42:17 -0700
Christoph Lameter [EMAIL PROTECTED] wrote:
+static noinline void vcompound_free(void *addr)
+{
+ if (in_interrupt()) {
Should be (in_interrupt() || irqs_disabled()) ?
Regards,
-Kame
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[13/17] Virtual compound page freeing in interrupt context
If we are in an interrupt context then simply defer the free via a workqueue.
Removing a virtual mappping *must* be done with interrupts enabled
since tlb_xx functions are called that rely on interrupts for
processor to processor communications.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
mm/page_alloc.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
Index: linux-2.6/mm/page_alloc.c
===
--- linux-2.6.orig/mm/page_alloc.c 2007-09-25 00:20:56.0 -0700
+++ linux-2.6/mm/page_alloc.c 2007-09-25 00:20:57.0 -0700
@@ -1294,7 +1294,12 @@ abort:
return NULL;
}
-static void vcompound_free(void *addr)
+/*
+ * Virtual Compound freeing functions. This is complicated by the vmalloc
+ * layer not being able to free virtual allocations when interrupts are
+ * disabled. So we defer the frees via a workqueue if necessary.
+ */
+static void __vcompound_free(void *addr)
{
struct page **pages;
int i;
@@ -1319,6 +1324,22 @@ static void vcompound_free(void *addr)
kfree(pages);
}
+static void vcompound_free_work(struct work_struct *w)
+{
+ __vcompound_free((void *)w);
+}
+
+static noinline void vcompound_free(void *addr)
+{
+ if (in_interrupt()) {
+ struct work_struct *w = addr;
+
+ INIT_WORK(w, vcompound_free_work);
+ schedule_work(w);
+ } else
+ __vcompound_free(addr);
+}
+
/*
* This is the 'heart' of the zoned buddy allocator.
*/
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[13/17] Virtual compound page freeing in interrupt context
If we are in an interrupt context then simply defer the free via a workqueue.
Removing a virtual mappping *must* be done with interrupts enabled
since tlb_xx functions are called that rely on interrupts for
processor to processor communications.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
mm/page_alloc.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
Index: linux-2.6/mm/page_alloc.c
===
--- linux-2.6.orig/mm/page_alloc.c 2007-09-25 00:20:56.0 -0700
+++ linux-2.6/mm/page_alloc.c 2007-09-25 00:20:57.0 -0700
@@ -1294,7 +1294,12 @@ abort:
return NULL;
}
-static void vcompound_free(void *addr)
+/*
+ * Virtual Compound freeing functions. This is complicated by the vmalloc
+ * layer not being able to free virtual allocations when interrupts are
+ * disabled. So we defer the frees via a workqueue if necessary.
+ */
+static void __vcompound_free(void *addr)
{
struct page **pages;
int i;
@@ -1319,6 +1324,22 @@ static void vcompound_free(void *addr)
kfree(pages);
}
+static void vcompound_free_work(struct work_struct *w)
+{
+ __vcompound_free((void *)w);
+}
+
+static noinline void vcompound_free(void *addr)
+{
+ if (in_interrupt()) {
+ struct work_struct *w = addr;
+
+ INIT_WORK(w, vcompound_free_work);
+ schedule_work(w);
+ } else
+ __vcompound_free(addr);
+}
+
/*
* This is the 'heart' of the zoned buddy allocator.
*/
--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [13/17] Virtual compound page freeing in interrupt context
On Wed, 19 Sep 2007, Nick Piggin wrote: > > Removing a virtual mappping *must* be done with interrupts enabled > > since tlb_xx functions are called that rely on interrupts for > > processor to processor communications. > > These things will clash drastically with my lazy TLB flushing and scalability > work. Actually the lazy TLB flushing will provide a natural way to defer > unmapping at interrupt time, and the scalability work should make it > easier to vmap from interrupt context too, if you really need that. Both would be good to have. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [13/17] Virtual compound page freeing in interrupt context
On Wednesday 19 September 2007 13:36, Christoph Lameter wrote:
> If we are in an interrupt context then simply defer the free via a
> workqueue.
>
> In an interrupt context it is not possible to use vmalloc_addr() to
> determine the vmalloc address. So add a variant that does that too.
>
> Removing a virtual mappping *must* be done with interrupts enabled
> since tlb_xx functions are called that rely on interrupts for
> processor to processor communications.
These things will clash drastically with my lazy TLB flushing and scalability
work. Actually the lazy TLB flushing will provide a natural way to defer
unmapping at interrupt time, and the scalability work should make it
easier to vmap from interrupt context too, if you really need that.
>
> Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
>
> ---
> mm/page_alloc.c | 23 ++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> Index: linux-2.6/mm/page_alloc.c
> ===
> --- linux-2.6.orig/mm/page_alloc.c2007-09-18 20:10:55.0 -0700
> +++ linux-2.6/mm/page_alloc.c 2007-09-18 20:11:40.0 -0700
> @@ -1297,7 +1297,12 @@ abort:
> return NULL;
> }
>
> -static void vcompound_free(void *addr)
> +/*
> + * Virtual Compound freeing functions. This is complicated by the vmalloc
> + * layer not being able to free virtual allocations when interrupts are
> + * disabled. So we defer the frees via a workqueue if necessary.
> + */
> +static void __vcompound_free(void *addr)
> {
> struct page **pages = vunmap(addr);
> int i;
> @@ -1320,6 +1325,22 @@ static void vcompound_free(void *addr)
> kfree(pages);
> }
>
> +static void vcompound_free_work(struct work_struct *w)
> +{
> + __vcompound_free((void *)w);
> +}
> +
> +static void vcompound_free(void *addr)
> +{
> + if (in_interrupt()) {
> + struct work_struct *w = addr;
> +
> + INIT_WORK(w, vcompound_free_work);
> + schedule_work(w);
> + } else
> + __vcompound_free(addr);
> +}
> +
> /*
> * This is the 'heart' of the zoned buddy allocator.
> */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [13/17] Virtual compound page freeing in interrupt context
On Wed, 19 Sep 2007, Nick Piggin wrote: Removing a virtual mappping *must* be done with interrupts enabled since tlb_xx functions are called that rely on interrupts for processor to processor communications. These things will clash drastically with my lazy TLB flushing and scalability work. Actually the lazy TLB flushing will provide a natural way to defer unmapping at interrupt time, and the scalability work should make it easier to vmap from interrupt context too, if you really need that. Both would be good to have. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[13/17] Virtual compound page freeing in interrupt context
If we are in an interrupt context then simply defer the free via a workqueue.
In an interrupt context it is not possible to use vmalloc_addr() to determine
the vmalloc address. So add a variant that does that too.
Removing a virtual mappping *must* be done with interrupts enabled
since tlb_xx functions are called that rely on interrupts for
processor to processor communications.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
mm/page_alloc.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
Index: linux-2.6/mm/page_alloc.c
===
--- linux-2.6.orig/mm/page_alloc.c 2007-09-18 20:10:55.0 -0700
+++ linux-2.6/mm/page_alloc.c 2007-09-18 20:11:40.0 -0700
@@ -1297,7 +1297,12 @@ abort:
return NULL;
}
-static void vcompound_free(void *addr)
+/*
+ * Virtual Compound freeing functions. This is complicated by the vmalloc
+ * layer not being able to free virtual allocations when interrupts are
+ * disabled. So we defer the frees via a workqueue if necessary.
+ */
+static void __vcompound_free(void *addr)
{
struct page **pages = vunmap(addr);
int i;
@@ -1320,6 +1325,22 @@ static void vcompound_free(void *addr)
kfree(pages);
}
+static void vcompound_free_work(struct work_struct *w)
+{
+ __vcompound_free((void *)w);
+}
+
+static void vcompound_free(void *addr)
+{
+ if (in_interrupt()) {
+ struct work_struct *w = addr;
+
+ INIT_WORK(w, vcompound_free_work);
+ schedule_work(w);
+ } else
+ __vcompound_free(addr);
+}
+
/*
* This is the 'heart' of the zoned buddy allocator.
*/
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[13/17] Virtual compound page freeing in interrupt context
If we are in an interrupt context then simply defer the free via a workqueue.
In an interrupt context it is not possible to use vmalloc_addr() to determine
the vmalloc address. So add a variant that does that too.
Removing a virtual mappping *must* be done with interrupts enabled
since tlb_xx functions are called that rely on interrupts for
processor to processor communications.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
mm/page_alloc.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
Index: linux-2.6/mm/page_alloc.c
===
--- linux-2.6.orig/mm/page_alloc.c 2007-09-18 20:10:55.0 -0700
+++ linux-2.6/mm/page_alloc.c 2007-09-18 20:11:40.0 -0700
@@ -1297,7 +1297,12 @@ abort:
return NULL;
}
-static void vcompound_free(void *addr)
+/*
+ * Virtual Compound freeing functions. This is complicated by the vmalloc
+ * layer not being able to free virtual allocations when interrupts are
+ * disabled. So we defer the frees via a workqueue if necessary.
+ */
+static void __vcompound_free(void *addr)
{
struct page **pages = vunmap(addr);
int i;
@@ -1320,6 +1325,22 @@ static void vcompound_free(void *addr)
kfree(pages);
}
+static void vcompound_free_work(struct work_struct *w)
+{
+ __vcompound_free((void *)w);
+}
+
+static void vcompound_free(void *addr)
+{
+ if (in_interrupt()) {
+ struct work_struct *w = addr;
+
+ INIT_WORK(w, vcompound_free_work);
+ schedule_work(w);
+ } else
+ __vcompound_free(addr);
+}
+
/*
* This is the 'heart' of the zoned buddy allocator.
*/
--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
