diff for duplicates of <527B1742.60400@hp.com> diff --git a/a/2.bin b/N1/2.bin index d3f80b5..13becce 100644 --- a/a/2.bin +++ b/N1/2.bin @@ -30,7 +30,7 @@ cite="mid:CA+55aFyNX=5i0hmk-KuD+Vk+yBD-kkAiywx1Lx_JJmHVPx=1wA@mail.gmail.com" but it will be unbearably slow, and add totally unnecessary serialization. So *correct* locking will require architecture support.</p> - <p dir="ltr">Â Â Â Â <br> + <p dir="ltr">A A A A <br> </p> </blockquote> <br> diff --git a/a/2.hdr b/N1/2.hdr index 6a9de1e..e9e8314 100644 --- a/a/2.hdr +++ b/N1/2.hdr @@ -1,2 +1,2 @@ Content-Type: text/html; charset=UTF-8 -Content-Transfer-Encoding: quoted-printable +Content-Transfer-Encoding: 8bit diff --git a/a/content_digest b/N1/content_digest index 4252096..814cd24 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -27,7 +27,10 @@ Scott J Norton <scott.norton@hp.com> linux-kernel@vger.kernel.org Thomas Gleixner <tglx@linutronix.de> - " Dave Hansen <dave.hansen@intel.com>\0" + Dave Hansen <dave.hansen@intel.com> + Matthew R Wilcox <matthew.r.wilcox@intel.com> + Will Deacon <will.deacon@arm.com> + " Davidlohr Bueso <davidlohr.bueso@hp.com>\0" "\01:1\0" "b\0" "On 11/06/2013 08:39 PM, Linus Torvalds wrote:\n" @@ -65,50 +68,50 @@ -Longman "\01:2\0" "b\0" - "<html>\r\n" - " <head>\r\n" - " <meta content=\"text/html; charset=UTF-8\" http-equiv=\"Content-Type\">\r\n" - " </head>\r\n" - " <body bgcolor=\"#FFFFFF\" text=\"#000000\">\r\n" - " On 11/06/2013 08:39 PM, Linus Torvalds wrote:\r\n" - " <blockquote\r\n" - "cite=\"mid:CA+55aFyNX=5i0hmk-KuD+Vk+yBD-kkAiywx1Lx_JJmHVPx=1wA@mail.gmail.com\"\r\n" - " type=\"cite\">\r\n" - " <meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\">\r\n" - " <p dir=\"ltr\">Sorry about the HTML crap, the internet connection is\r\n" - " too slow for my normal email habits, so I'm using my phone. </p>\r\n" - " <p dir=\"ltr\">I think the barriers are still totally wrong for the\r\n" - " locking functions.</p>\r\n" - " <p dir=\"ltr\">Adding an smp_rmb after waiting for the lock is pure\r\n" - " BS. Writes in the locked region could percolate out of the\r\n" - " locked region.</p>\r\n" - " <p dir=\"ltr\">The thing is, you cannot do the memory ordering for\r\n" - " locks in any same generic way. Not using our current barrier\r\n" - " system. On x86 (and many others) the smp_rmb will work fine,\r\n" - " because writes are never moved earlier. But on other\r\n" - " architectures you really need an acquire to get a lock\r\n" - " efficiently. No separate barriers. An acquire needs to be on the\r\n" - " instruction that does the lock.</p>\r\n" - " <p dir=\"ltr\">Same goes for unlock. On x86 any store is a fine\r\n" - " unlock, but on other architectures you need a store with a\r\n" - " release marker.</p>\r\n" - " <p dir=\"ltr\">So no amount of barriers will ever do this correctly.\r\n" - " Sure, you can add full memory barriers and it will be \"correct\"\r\n" - " but it will be unbearably slow, and add totally unnecessary\r\n" - " serialization. So *correct* locking will require architecture\r\n" - " support.</p>\r\n" - " <p dir=\"ltr\">\302\240\302\240\302\240\302\240 <br>\r\n" - " </p>\r\n" - " </blockquote>\r\n" - " <br>\r\n" - " Yes, we realized that we can't do it in a generic way without\r\n" - " introducing unwanted overhead. So I had sent out another patch to do\r\n" - " it in an architecture specific way to enable each architecture to\r\n" - " choose their memory barrier. It was at the end of the v3 and v4\r\n" - " patch series.<br>\r\n" - " <br>\r\n" - " -Longman<br>\r\n" - " </body>\r\n" - "</html>\r\n" + "<html>\n" + " <head>\n" + " <meta content=\"text/html; charset=UTF-8\" http-equiv=\"Content-Type\">\n" + " </head>\n" + " <body bgcolor=\"#FFFFFF\" text=\"#000000\">\n" + " On 11/06/2013 08:39 PM, Linus Torvalds wrote:\n" + " <blockquote\n" + "cite=\"mid:CA+55aFyNX=5i0hmk-KuD+Vk+yBD-kkAiywx1Lx_JJmHVPx=1wA@mail.gmail.com\"\n" + " type=\"cite\">\n" + " <meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\">\n" + " <p dir=\"ltr\">Sorry about the HTML crap, the internet connection is\n" + " too slow for my normal email habits, so I'm using my phone. </p>\n" + " <p dir=\"ltr\">I think the barriers are still totally wrong for the\n" + " locking functions.</p>\n" + " <p dir=\"ltr\">Adding an smp_rmb after waiting for the lock is pure\n" + " BS. Writes in the locked region could percolate out of the\n" + " locked region.</p>\n" + " <p dir=\"ltr\">The thing is, you cannot do the memory ordering for\n" + " locks in any same generic way. Not using our current barrier\n" + " system. On x86 (and many others) the smp_rmb will work fine,\n" + " because writes are never moved earlier. But on other\n" + " architectures you really need an acquire to get a lock\n" + " efficiently. No separate barriers. An acquire needs to be on the\n" + " instruction that does the lock.</p>\n" + " <p dir=\"ltr\">Same goes for unlock. On x86 any store is a fine\n" + " unlock, but on other architectures you need a store with a\n" + " release marker.</p>\n" + " <p dir=\"ltr\">So no amount of barriers will ever do this correctly.\n" + " Sure, you can add full memory barriers and it will be \"correct\"\n" + " but it will be unbearably slow, and add totally unnecessary\n" + " serialization. So *correct* locking will require architecture\n" + " support.</p>\n" + " <p dir=\"ltr\">A A A A <br>\n" + " </p>\n" + " </blockquote>\n" + " <br>\n" + " Yes, we realized that we can't do it in a generic way without\n" + " introducing unwanted overhead. So I had sent out another patch to do\n" + " it in an architecture specific way to enable each architecture to\n" + " choose their memory barrier. It was at the end of the v3 and v4\n" + " patch series.<br>\n" + " <br>\n" + " -Longman<br>\n" + " </body>\n" + "</html>\n" -7ba87e5e78d23e1e30316e51fd7cbedf9acbf592bdf17f967adb1e1ef73e114f +db0c2a761f6203426bec39c27d6ca13591a94454142d6c1681854534a000de75
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.