diff for duplicates of <20101006123753.GA17674@localhost> diff --git a/a/1.txt b/N1/1.txt index bfd65f3..1aecc13 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -9,8 +9,8 @@ On Wed, Oct 06, 2010 at 11:01:35AM +0300, Pekka Enberg wrote: > > - Lots of debugging > > - Performance optimizations (more would be good)... > > - Drop per slab locking in favor of per node locking for -> > partial lists (queuing implies freeing large amounts of objects -> > to per node lists of slab). +> > A partial lists (queuing implies freeing large amounts of objects +> > A to per node lists of slab). > > - Implement object expiration via reclaim VM logic. > > > > The following is a release of an allocator based on SLAB @@ -22,15 +22,15 @@ On Wed, Oct 06, 2010 at 11:01:35AM +0300, Pekka Enberg wrote: > > like SLAB attemped to. There are a number of architectural differences: > > > > 1. SLUB accurately tracks cpu caches instead of assuming that there -> > is only a single cpu cache per node or system. +> > A is only a single cpu cache per node or system. > > > > 2. SLUB object expiration is tied into the page reclaim logic. There -> > is no periodic cache expiration. +> > A is no periodic cache expiration. > > > > 3. SLUB caches are dynamically configurable via the sysfs filesystem. > > > > 4. There is no per slab page metadata structure to maintain (aside -> > from the object bitmap that usually fits into the page struct). +> > A from the object bitmap that usually fits into the page struct). > > > > 5. Has all the resiliency and diagnostic features of SLUB. > > @@ -50,19 +50,19 @@ On Wed, Oct 06, 2010 at 11:01:35AM +0300, Pekka Enberg wrote: > > > > Dell R910 128G RAM, 64 processors, 4 NUMA nodes > > -> > threads unified slub slab -> > 64 4141798 3729037 3884939 -> > 128 4146587 3890993 4105276 -> > 192 4003063 3876570 4110971 -> > 256 3928857 3942806 4099249 -> > 320 3922623 3969042 4093283 -> > 384 3827603 4002833 4108420 -> > 448 4140345 4027251 4118534 -> > 512 4163741 4050130 4122644 -> > 576 4175666 4099934 4149355 -> > 640 4190332 4142570 4175618 -> > 704 4198779 4173177 4193657 -> > 768 4662216 4200462 4222686 +> > threads unified A A A A slub A A A A A A slab +> > 64 A A A 4141798 A A A A 3729037 A A A A 3884939 +> > 128 A A 4146587 A A A A 3890993 A A A A 4105276 +> > 192 A A 4003063 A A A A 3876570 A A A A 4110971 +> > 256 A A 3928857 A A A A 3942806 A A A A 4099249 +> > 320 A A 3922623 A A A A 3969042 A A A A 4093283 +> > 384 A A 3827603 A A A A 4002833 A A A A 4108420 +> > 448 A A 4140345 A A A A 4027251 A A A A 4118534 +> > 512 A A 4163741 A A A A 4050130 A A A A 4122644 +> > 576 A A 4175666 A A A A 4099934 A A A A 4149355 +> > 640 A A 4190332 A A A A 4142570 A A A A 4175618 +> > 704 A A 4198779 A A A A 4173177 A A A A 4193657 +> > 768 A A 4662216 A A A A 4200462 A A A A 4222686 > > Are there any stability problems left? Have you tried other benchmarks > (e.g. hackbench, sysbench)? Can we merge the series in smaller @@ -74,3 +74,9 @@ On Wed, Oct 06, 2010 at 11:01:35AM +0300, Pekka Enberg wrote: > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> + +-- +To unsubscribe, send a message with 'unsubscribe linux-mm' in +the body to majordomo@kvack.org. For more info on Linux MM, +see: http://www.linux-mm.org/ . +Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> diff --git a/a/content_digest b/N1/content_digest index 86f8638..0d64160 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -27,8 +27,8 @@ "> > - Lots of debugging\n" "> > - Performance optimizations (more would be good)...\n" "> > - Drop per slab locking in favor of per node locking for\n" - "> > \302\240partial lists (queuing implies freeing large amounts of objects\n" - "> > \302\240to per node lists of slab).\n" + "> > A partial lists (queuing implies freeing large amounts of objects\n" + "> > A to per node lists of slab).\n" "> > - Implement object expiration via reclaim VM logic.\n" "> >\n" "> > The following is a release of an allocator based on SLAB\n" @@ -40,15 +40,15 @@ "> > like SLAB attemped to. There are a number of architectural differences:\n" "> >\n" "> > 1. SLUB accurately tracks cpu caches instead of assuming that there\n" - "> > \302\240 is only a single cpu cache per node or system.\n" + "> > A is only a single cpu cache per node or system.\n" "> >\n" "> > 2. SLUB object expiration is tied into the page reclaim logic. There\n" - "> > \302\240 is no periodic cache expiration.\n" + "> > A is no periodic cache expiration.\n" "> >\n" "> > 3. SLUB caches are dynamically configurable via the sysfs filesystem.\n" "> >\n" "> > 4. There is no per slab page metadata structure to maintain (aside\n" - "> > \302\240 from the object bitmap that usually fits into the page struct).\n" + "> > A from the object bitmap that usually fits into the page struct).\n" "> >\n" "> > 5. Has all the resiliency and diagnostic features of SLUB.\n" "> >\n" @@ -68,19 +68,19 @@ "> >\n" "> > Dell R910 128G RAM, 64 processors, 4 NUMA nodes\n" "> >\n" - "> > threads unified \302\240 \302\240 \302\240 \302\240 slub \302\240 \302\240 \302\240 \302\240 \302\240 \302\240slab\n" - "> > 64 \302\240 \302\240 \302\2404141798 \302\240 \302\240 \302\240 \302\240 3729037 \302\240 \302\240 \302\240 \302\240 3884939\n" - "> > 128 \302\240 \302\240 4146587 \302\240 \302\240 \302\240 \302\240 3890993 \302\240 \302\240 \302\240 \302\240 4105276\n" - "> > 192 \302\240 \302\240 4003063 \302\240 \302\240 \302\240 \302\240 3876570 \302\240 \302\240 \302\240 \302\240 4110971\n" - "> > 256 \302\240 \302\240 3928857 \302\240 \302\240 \302\240 \302\240 3942806 \302\240 \302\240 \302\240 \302\240 4099249\n" - "> > 320 \302\240 \302\240 3922623 \302\240 \302\240 \302\240 \302\240 3969042 \302\240 \302\240 \302\240 \302\240 4093283\n" - "> > 384 \302\240 \302\240 3827603 \302\240 \302\240 \302\240 \302\240 4002833 \302\240 \302\240 \302\240 \302\240 4108420\n" - "> > 448 \302\240 \302\240 4140345 \302\240 \302\240 \302\240 \302\240 4027251 \302\240 \302\240 \302\240 \302\240 4118534\n" - "> > 512 \302\240 \302\240 4163741 \302\240 \302\240 \302\240 \302\240 4050130 \302\240 \302\240 \302\240 \302\240 4122644\n" - "> > 576 \302\240 \302\240 4175666 \302\240 \302\240 \302\240 \302\240 4099934 \302\240 \302\240 \302\240 \302\240 4149355\n" - "> > 640 \302\240 \302\240 4190332 \302\240 \302\240 \302\240 \302\240 4142570 \302\240 \302\240 \302\240 \302\240 4175618\n" - "> > 704 \302\240 \302\240 4198779 \302\240 \302\240 \302\240 \302\240 4173177 \302\240 \302\240 \302\240 \302\240 4193657\n" - "> > 768 \302\240 \302\240 4662216 \302\240 \302\240 \302\240 \302\240 4200462 \302\240 \302\240 \302\240 \302\240 4222686\n" + "> > threads unified A A A A slub A A A A A A slab\n" + "> > 64 A A A 4141798 A A A A 3729037 A A A A 3884939\n" + "> > 128 A A 4146587 A A A A 3890993 A A A A 4105276\n" + "> > 192 A A 4003063 A A A A 3876570 A A A A 4110971\n" + "> > 256 A A 3928857 A A A A 3942806 A A A A 4099249\n" + "> > 320 A A 3922623 A A A A 3969042 A A A A 4093283\n" + "> > 384 A A 3827603 A A A A 4002833 A A A A 4108420\n" + "> > 448 A A 4140345 A A A A 4027251 A A A A 4118534\n" + "> > 512 A A 4163741 A A A A 4050130 A A A A 4122644\n" + "> > 576 A A 4175666 A A A A 4099934 A A A A 4149355\n" + "> > 640 A A 4190332 A A A A 4142570 A A A A 4175618\n" + "> > 704 A A 4198779 A A A A 4173177 A A A A 4193657\n" + "> > 768 A A 4662216 A A A A 4200462 A A A A 4222686\n" "> \n" "> Are there any stability problems left? Have you tried other benchmarks\n" "> (e.g. hackbench, sysbench)? Can we merge the series in smaller\n" @@ -91,6 +91,12 @@ "> To unsubscribe, send a message with 'unsubscribe linux-mm' in\n" "> the body to majordomo@kvack.org. For more info on Linux MM,\n" "> see: http://www.linux-mm.org/ .\n" - "> Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" + "> Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>\n" + "\n" + "--\n" + "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n" + "the body to majordomo@kvack.org. For more info on Linux MM,\n" + "see: http://www.linux-mm.org/ .\n" + "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" -296173addb465cf223a824dc4e570f774df2edd58f891aca79d7764eab4bf1b3 +a4d4cb4cb4be3c8f9d765c2de2b7f1e42be83b25b26a13189352dec9fa04ff27
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.