diff for duplicates of <1810068989.20081223175240@emcraft.com> diff --git a/a/1.txt b/N1/1.txt index 2aea08e..8e28cb4 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,17 +1,18 @@ -=0D=0A Hello Hugh, + + Hello Hugh, On Tuesday, December 23, 2008 you wrote: > On Fri, 19 Dec 2008, Yuri Tikhonov wrote: ->>=20 +>> >> The following patch fixes division by zero, which we have in >> shmem_truncate_range() and shmem_unuse_inode(), if use big >> PAGE_SIZE values (e.g. 256KB on ppc44x). ->>=20 +>> >> With 256KB PAGE_SIZE the ENTRIES_PER_PAGEPAGE constant becomes >> too large (0x1.0000.0000), so this patch just changes the types >> from 'ulong' to 'ullong' where it's necessary. ->>=20 +>> >> Signed-off-by: Yuri Tikhonov <yur@emcraft.com> > Sorry for the slow reply, but I'm afraid I don't like spattering @@ -36,33 +37,33 @@ On Tuesday, December 23, 2008 you wrote: > this change appears to be for a 32-bit machine with 256KB pages. > I wonder what market segment that is targeted at? - Right, sizeof(unsigned long long)=3D=3D8 on our ppc44x target. + Right, sizeof(unsigned long long)==8 on our ppc44x target. - The main processor here is a PPC440SPe from AMCC, which is a 32-bit=20 -RISC machine with 36-bit physical addressing.=20 + The main processor here is a PPC440SPe from AMCC, which is a 32-bit +RISC machine with 36-bit physical addressing. - The market segment for this are RAID applications. The Linux s/w RAID=20 + The market segment for this are RAID applications. The Linux s/w RAID driver had been significantly reworked over the last years, and now it -allows efficiently offload the RAID-related operations (as well as=20 -the data copy) from CPU to the dedicated engines via ASYN_TX/ADMA=20 -API. The 440SPe controller has a reach RAID-related peripheral=20 -integrated on chip: XOR engine and two DMA engines with different=20 -capabilities including XOR calculations/checks for RAID5/6, PQ=20 -parities calculations/checks for RAID6, memory copy, and so on. All=20 -these make 440SPe to be a good choice for developing RAID storage=20 +allows efficiently offload the RAID-related operations (as well as +the data copy) from CPU to the dedicated engines via ASYN_TX/ADMA +API. The 440SPe controller has a reach RAID-related peripheral +integrated on chip: XOR engine and two DMA engines with different +capabilities including XOR calculations/checks for RAID5/6, PQ +parities calculations/checks for RAID6, memory copy, and so on. All +these make 440SPe to be a good choice for developing RAID storage applications. - By increasing the PAGE_SIZE we improve the performance of RAID=20 -operations, because the RAID stripes (on which basic the Linux RAID=20 -driver operates) have a PAGE_SIZE width: so, the bigger the strip is,=20 -then the less CPU cycles are necessary to process the same chunk of=20 -data. The value of improvement differs from case to case, and has the=20 + By increasing the PAGE_SIZE we improve the performance of RAID +operations, because the RAID stripes (on which basic the Linux RAID +driver operates) have a PAGE_SIZE width: so, the bigger the strip is, +then the less CPU cycles are necessary to process the same chunk of +data. The value of improvement differs from case to case, and has the maximum number in such cases like sequential writes. - For example, on the ppc440spe-base Katmai board we observe the=20 -following performance distribution of sequential writes to RAID-5=20 -built on 16 drives (actually, we can achieve higher performance if=20 -skipping RAID caching of the data; the following figures are measured=20 + For example, on the ppc440spe-base Katmai board we observe the +following performance distribution of sequential writes to RAID-5 +built on 16 drives (actually, we can achieve higher performance if +skipping RAID caching of the data; the following figures are measured involving the RAID caching): 4K PAGE_SIZE: s/w: 84 MBps; h/w accelerated: 172 MBps diff --git a/a/content_digest b/N1/content_digest index 6ea1aef..a715bbf 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -4,32 +4,33 @@ "Subject\0Re[2]: [PATCH] mm/shmem.c: fix division by zero\0" "Date\0Tue, 23 Dec 2008 17:52:40 +0300\0" "To\0Hugh Dickins <hugh@veritas.com>\0" - "Cc\0wd@denx.de" - dzu@denx.de - linux-kernel@vger.kernel.org - miltonm@bga.com + "Cc\0linux-kernel@vger.kernel.org" linuxppc-dev@ozlabs.org - paulus@samba.org - viro@zeniv.linux.org.uk - Geert.Uytterhoeven@sonycom.com - yanok@emcraft.com - " akpm@linux-foundation.org\0" + <akpm@linux-foundation.org> + <paulus@samba.org> + <wd@denx.de> + <dzu@denx.de> + <yanok@emcraft.com> + <miltonm@bga.com> + <viro@zeniv.linux.org.uk> + " <Geert.Uytterhoeven@sonycom.com>\0" "\00:1\0" "b\0" - "=0D=0A Hello Hugh,\n" + "\n" + " Hello Hugh,\n" "\n" "On Tuesday, December 23, 2008 you wrote:\n" "\n" "> On Fri, 19 Dec 2008, Yuri Tikhonov wrote:\n" - ">>=20\n" + ">> \n" ">> The following patch fixes division by zero, which we have in\n" ">> shmem_truncate_range() and shmem_unuse_inode(), if use big\n" ">> PAGE_SIZE values (e.g. 256KB on ppc44x).\n" - ">>=20\n" + ">> \n" ">> With 256KB PAGE_SIZE the ENTRIES_PER_PAGEPAGE constant becomes\n" ">> too large (0x1.0000.0000), so this patch just changes the types\n" ">> from 'ulong' to 'ullong' where it's necessary.\n" - ">>=20\n" + ">> \n" ">> Signed-off-by: Yuri Tikhonov <yur@emcraft.com>\n" "\n" "> Sorry for the slow reply, but I'm afraid I don't like spattering\n" @@ -54,33 +55,33 @@ "> this change appears to be for a 32-bit machine with 256KB pages.\n" "> I wonder what market segment that is targeted at?\n" "\n" - " Right, sizeof(unsigned long long)=3D=3D8 on our ppc44x target.\n" + " Right, sizeof(unsigned long long)==8 on our ppc44x target.\n" "\n" - " The main processor here is a PPC440SPe from AMCC, which is a 32-bit=20\n" - "RISC machine with 36-bit physical addressing.=20\n" + " The main processor here is a PPC440SPe from AMCC, which is a 32-bit \n" + "RISC machine with 36-bit physical addressing. \n" "\n" - " The market segment for this are RAID applications. The Linux s/w RAID=20\n" + " The market segment for this are RAID applications. The Linux s/w RAID \n" "driver had been significantly reworked over the last years, and now it\n" - "allows efficiently offload the RAID-related operations (as well as=20\n" - "the data copy) from CPU to the dedicated engines via ASYN_TX/ADMA=20\n" - "API. The 440SPe controller has a reach RAID-related peripheral=20\n" - "integrated on chip: XOR engine and two DMA engines with different=20\n" - "capabilities including XOR calculations/checks for RAID5/6, PQ=20\n" - "parities calculations/checks for RAID6, memory copy, and so on. All=20\n" - "these make 440SPe to be a good choice for developing RAID storage=20\n" + "allows efficiently offload the RAID-related operations (as well as \n" + "the data copy) from CPU to the dedicated engines via ASYN_TX/ADMA \n" + "API. The 440SPe controller has a reach RAID-related peripheral \n" + "integrated on chip: XOR engine and two DMA engines with different \n" + "capabilities including XOR calculations/checks for RAID5/6, PQ \n" + "parities calculations/checks for RAID6, memory copy, and so on. All \n" + "these make 440SPe to be a good choice for developing RAID storage \n" "applications.\n" "\n" - " By increasing the PAGE_SIZE we improve the performance of RAID=20\n" - "operations, because the RAID stripes (on which basic the Linux RAID=20\n" - "driver operates) have a PAGE_SIZE width: so, the bigger the strip is,=20\n" - "then the less CPU cycles are necessary to process the same chunk of=20\n" - "data. The value of improvement differs from case to case, and has the=20\n" + " By increasing the PAGE_SIZE we improve the performance of RAID \n" + "operations, because the RAID stripes (on which basic the Linux RAID \n" + "driver operates) have a PAGE_SIZE width: so, the bigger the strip is, \n" + "then the less CPU cycles are necessary to process the same chunk of \n" + "data. The value of improvement differs from case to case, and has the \n" "maximum number in such cases like sequential writes.\n" "\n" - " For example, on the ppc440spe-base Katmai board we observe the=20\n" - "following performance distribution of sequential writes to RAID-5=20\n" - "built on 16 drives (actually, we can achieve higher performance if=20\n" - "skipping RAID caching of the data; the following figures are measured=20\n" + " For example, on the ppc440spe-base Katmai board we observe the \n" + "following performance distribution of sequential writes to RAID-5 \n" + "built on 16 drives (actually, we can achieve higher performance if \n" + "skipping RAID caching of the data; the following figures are measured \n" "involving the RAID caching):\n" "\n" " 4K PAGE_SIZE: s/w: 84 MBps; h/w accelerated: 172 MBps\n" @@ -94,4 +95,4 @@ " Yuri Tikhonov, Senior Software Engineer\n" Emcraft Systems, www.emcraft.com -451151902740c4811e75c291c2ad3e52e0320b82717397a4d43e64097187c657 +9fa41c27cb6c0083648a8654a9fc6b5ce3ef87e76206070ab55272dee6eb21fd
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.