On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyng...@arm.com> wrote:

> > -static int unmap_and_move(new_page_t get_new_page, free_page_t 
> > put_new_page,
> > -                   unsigned long private, struct page *page, int force,
> > -                   enum migrate_mode mode)
> > +static noinline int unmap_and_move(new_page_t get_new_page,
> > +                              free_page_t put_new_page,
> > +                              unsigned long private, struct page *page,
> > +                              int force, enum migrate_mode mode)
> >  {
> >     int rc = 0;
> >     int *result = NULL;
> > 
> 
> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
> the parameters on the stack, which is not going to help performance
> either (not that this would be useful on 32bit ARM anyway...).
> 
> Any chance you could make this dependent on some compiler detection
> mechanism?

With my arm compiler (gcc-4.4.4) the patch makes no difference -
unmap_and_move() isn't being inlined anyway.

How does this look?

Kevin, could you please retest?  I might have fat-fingered something...

--- 
a/mm/migrate.c~mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473-fix
+++ a/mm/migrate.c
@@ -901,10 +901,20 @@ out:
 }
 
 /*
+ * gcc-4.7.3 on arm gets an ICE when inlining unmap_and_move().  Work around
+ * it.
+ */
+#if GCC_VERSION == 40703 && defined(CONFIG_ARM)
+#define ICE_noinline noinline
+#else
+#define ICE_noinline
+#endif
+
+/*
  * Obtain the lock on page, remove all ptes and migrate the page
  * to the newly allocated page in newpage.
  */
-static noinline int unmap_and_move(new_page_t get_new_page,
+static ICE_noinline int unmap_and_move(new_page_t get_new_page,
                                   free_page_t put_new_page,
                                   unsigned long private, struct page *page,
                                   int force, enum migrate_mode mode)
_

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to