On Fri, Jul 12, 2013 at 09:31:42AM -0700, Dave Hansen wrote:
> On 07/10/2013 11:12 PM, Joonsoo Kim wrote:
> > On Wed, Jul 10, 2013 at 10:38:20PM -0700, Dave Hansen wrote:
> >> You're probably right for small numbers of pages. But, if we're talking
> >> about things that are more than, say, 100
On Thu, Jul 11, 2013 at 08:51:22AM -0700, Dave Hansen wrote:
> On 07/10/2013 11:12 PM, Joonsoo Kim wrote:
> >> > I'd also like to see some scalability numbers on this. How do your
> >> > tests look when all the CPUs on the system are hammering away?
> > What test do you mean?
> > Please elaborate
On Thu, Jul 11, 2013 at 08:51:22AM -0700, Dave Hansen wrote:
On 07/10/2013 11:12 PM, Joonsoo Kim wrote:
I'd also like to see some scalability numbers on this. How do your
tests look when all the CPUs on the system are hammering away?
What test do you mean?
Please elaborate on this more
On Fri, Jul 12, 2013 at 09:31:42AM -0700, Dave Hansen wrote:
On 07/10/2013 11:12 PM, Joonsoo Kim wrote:
On Wed, Jul 10, 2013 at 10:38:20PM -0700, Dave Hansen wrote:
You're probably right for small numbers of pages. But, if we're talking
about things that are more than, say, 100 pages
On 07/10/2013 11:12 PM, Joonsoo Kim wrote:
> On Wed, Jul 10, 2013 at 10:38:20PM -0700, Dave Hansen wrote:
>> You're probably right for small numbers of pages. But, if we're talking
>> about things that are more than, say, 100 pages (isn't the pcp batch
>> size clamped to 128 4k pages?) you surely
On 07/10/2013 11:12 PM, Joonsoo Kim wrote:
On Wed, Jul 10, 2013 at 10:38:20PM -0700, Dave Hansen wrote:
You're probably right for small numbers of pages. But, if we're talking
about things that are more than, say, 100 pages (isn't the pcp batch
size clamped to 128 4k pages?) you surely don't
On 07/10/2013 11:12 PM, Joonsoo Kim wrote:
>> > I'd also like to see some scalability numbers on this. How do your
>> > tests look when all the CPUs on the system are hammering away?
> What test do you mean?
> Please elaborate on this more
Your existing tests looked single-threaded. That's
On Wed, Jul 10, 2013 at 10:38:20PM -0700, Dave Hansen wrote:
> On 07/10/2013 06:02 PM, Joonsoo Kim wrote:
> > On Wed, Jul 10, 2013 at 03:52:42PM -0700, Dave Hansen wrote:
> >> On 07/03/2013 01:34 AM, Joonsoo Kim wrote:
> >>> - if (page)
> >>> + do {
> >>> + page =
On Wed, Jul 10, 2013 at 10:38:20PM -0700, Dave Hansen wrote:
On 07/10/2013 06:02 PM, Joonsoo Kim wrote:
On Wed, Jul 10, 2013 at 03:52:42PM -0700, Dave Hansen wrote:
On 07/03/2013 01:34 AM, Joonsoo Kim wrote:
- if (page)
+ do {
+ page =
On 07/10/2013 11:12 PM, Joonsoo Kim wrote:
I'd also like to see some scalability numbers on this. How do your
tests look when all the CPUs on the system are hammering away?
What test do you mean?
Please elaborate on this more
Your existing tests looked single-threaded. That's certainly
On 07/10/2013 06:02 PM, Joonsoo Kim wrote:
> On Wed, Jul 10, 2013 at 03:52:42PM -0700, Dave Hansen wrote:
>> On 07/03/2013 01:34 AM, Joonsoo Kim wrote:
>>> - if (page)
>>> + do {
>>> + page = buffered_rmqueue(preferred_zone, zone, order,
>>> +
On Wed, Jul 10, 2013 at 03:52:42PM -0700, Dave Hansen wrote:
> On 07/03/2013 01:34 AM, Joonsoo Kim wrote:
> > - if (page)
> > + do {
> > + page = buffered_rmqueue(preferred_zone, zone, order,
> > + gfp_mask,
On 07/03/2013 01:34 AM, Joonsoo Kim wrote:
> - if (page)
> + do {
> + page = buffered_rmqueue(preferred_zone, zone, order,
> + gfp_mask, migratetype);
> + if (!page)
> +
On 07/03/2013 01:34 AM, Joonsoo Kim wrote:
- if (page)
+ do {
+ page = buffered_rmqueue(preferred_zone, zone, order,
+ gfp_mask, migratetype);
+ if (!page)
+
On Wed, Jul 10, 2013 at 03:52:42PM -0700, Dave Hansen wrote:
On 07/03/2013 01:34 AM, Joonsoo Kim wrote:
- if (page)
+ do {
+ page = buffered_rmqueue(preferred_zone, zone, order,
+ gfp_mask,
On 07/10/2013 06:02 PM, Joonsoo Kim wrote:
On Wed, Jul 10, 2013 at 03:52:42PM -0700, Dave Hansen wrote:
On 07/03/2013 01:34 AM, Joonsoo Kim wrote:
- if (page)
+ do {
+ page = buffered_rmqueue(preferred_zone, zone, order,
+
On Wed, Jul 03, 2013 at 03:57:45PM +, Christoph Lameter wrote:
> On Wed, 3 Jul 2013, Joonsoo Kim wrote:
>
> > @@ -298,13 +298,15 @@ static inline void arch_alloc_page(struct page *page,
> > int order) { }
> >
> > struct page *
> > __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order,
On Wed, 3 Jul 2013, Joonsoo Kim wrote:
> @@ -298,13 +298,15 @@ static inline void arch_alloc_page(struct page *page,
> int order) { }
>
> struct page *
> __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order,
> -struct zonelist *zonelist, nodemask_t *nodemask);
> +
This patch introduces multiple pages allocation feature to buddy
allocator. Currently, there is no ability to allocate multiple
pages at once, so we should invoke single page allocation logic
repeatedly. This has some overheads like as function call
overhead with many arguments and overhead for
This patch introduces multiple pages allocation feature to buddy
allocator. Currently, there is no ability to allocate multiple
pages at once, so we should invoke single page allocation logic
repeatedly. This has some overheads like as function call
overhead with many arguments and overhead for
On Wed, 3 Jul 2013, Joonsoo Kim wrote:
@@ -298,13 +298,15 @@ static inline void arch_alloc_page(struct page *page,
int order) { }
struct page *
__alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order,
-struct zonelist *zonelist, nodemask_t *nodemask);
+
On Wed, Jul 03, 2013 at 03:57:45PM +, Christoph Lameter wrote:
On Wed, 3 Jul 2013, Joonsoo Kim wrote:
@@ -298,13 +298,15 @@ static inline void arch_alloc_page(struct page *page,
int order) { }
struct page *
__alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order,
-
22 matches
Mail list logo
