All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: tim@xen.org, sstabellini@kernel.org, wei.liu2@citrix.com,
	George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [PATCH v2 1/9] mm: Separate free page chunk merging into its own routine
Date: Tue, 4 Apr 2017 09:48:56 -0400	[thread overview]
Message-ID: <64f16622-6614-1ef5-d232-98d2c9c8326d@oracle.com> (raw)
In-Reply-To: <58E39CB2020000780014C8DF@prv-mh.provo.novell.com>

On 04/04/2017 07:16 AM, Jan Beulich wrote:
>>>> On 03.04.17 at 18:50, <boris.ostrovsky@oracle.com> wrote:
>> --- a/xen/common/page_alloc.c
>> +++ b/xen/common/page_alloc.c
>> @@ -924,11 +924,64 @@ static int reserve_offlined_page(struct page_info *head)
>>      return count;
>>  }
>>  
>> +static bool_t can_merge(struct page_info *buddy, unsigned int node,
> Plain bool please, and const for the pointer.

Wei asked for that too but it wasn't clear to me what the hypervisor
preference is. We currently have much higher use of bool_t than bool
(1015 vs 321, according to cscope). page_alloc.c uses only the former.

>
>> +{
>> +    if ( !mfn_valid(_mfn(page_to_mfn(buddy))) ||
>> +         !page_state_is(buddy, free) ||
> As a helper of freeing, this is fine, but then the name of both
> functions is too generic: Fundamentally certain other page types
> might be mergeable too.

merge_free_chunks()/can_merge_free() ?

>
>> +         (PFN_ORDER(buddy) != order) ||
>> +         (phys_to_nid(page_to_maddr(buddy)) != node) )
>> +        return false;
>> +
>> +    return true;
> Is there any reason not to make this a single return statement? I
> don't think it would be any worse to read.

See patches 2 and 7, where more checks are added. While those two might
be merged (they both deal with scrubbing) , combining all 3 of them into
a single statement would make it a bit difficult to read IMO.

>
>> +static struct page_info *merge_chunks(struct page_info *pg, unsigned int node,
>> +                                      unsigned int zone, unsigned int order)
>> +{
>> +    ASSERT(spin_is_locked(&heap_lock));
>> +
>> +    /* Merge chunks as far as possible. */
>> +    while ( order < MAX_ORDER )
>> +    {
>> +        unsigned long mask = 1UL << order;
>> +        struct page_info *buddy;
>> +
>> +        if ( (page_to_mfn(pg) & mask) )
>> +        {
>> +            /* Merge with predecessor block? */
>> +            buddy = pg - mask;
>> +            if ( !can_merge(buddy, node, order) )
>> +                break;
>> +
>> +            pg = buddy;
>> +            page_list_del(pg, &heap(node, zone, order));
>> +        }
>> +        else
>> +        {
>> +            /* Merge with successor block? */
>> +            buddy = pg + mask;
>> +            if ( !can_merge(buddy, node, order) )
>> +                break;
>> +
>> +            page_list_del(buddy, &heap(node, zone, order));
> This and its companion in the if() branch are now the same (taking
> into account the assignment ahead of the former) - please move
> them past the if/else.
>
>> +        }
>> +
>> +        order++;
>> +    }
>> +
>> +    PFN_ORDER(pg) = order;
>> +    page_list_add_tail(pg, &heap(node, zone, order));
> I don't think this strictly is part of the merge anymore, so judging
> by the name of the function this last line would rather belong into
> the caller.

All users of merge_chunks() want to place the new chunk back into the
heap and I don't think I see why anyone would want to just get the new
buddy without putting it there.

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  reply	other threads:[~2017-04-04 13:48 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-03 16:50 [PATCH v2 0/9] Memory scrubbing from idle loop Boris Ostrovsky
2017-04-03 16:50 ` [PATCH v2 1/9] mm: Separate free page chunk merging into its own routine Boris Ostrovsky
2017-04-04 11:16   ` Jan Beulich
2017-04-04 13:48     ` Boris Ostrovsky [this message]
2017-04-04 14:01       ` Jan Beulich
2017-04-04 14:23         ` Boris Ostrovsky
2017-04-03 16:50 ` [PATCH v2 2/9] mm: Place unscrubbed pages at the end of pagelist Boris Ostrovsky
2017-04-04 14:46   ` Jan Beulich
2017-04-04 15:14     ` Boris Ostrovsky
2017-04-04 15:29       ` Jan Beulich
2017-04-04 15:39         ` Boris Ostrovsky
2017-04-04 15:50           ` Jan Beulich
2017-04-04 16:22             ` Boris Ostrovsky
2017-04-03 16:50 ` [PATCH v2 3/9] mm: Scrub pages in alloc_heap_pages() if needed Boris Ostrovsky
2017-04-03 16:50 ` [PATCH v2 4/9] mm: Scrub memory from idle loop Boris Ostrovsky
2017-04-12 16:11   ` Jan Beulich
2017-04-03 16:50 ` [PATCH v2 5/9] mm: Do not discard already-scrubbed pages softirqs are pending Boris Ostrovsky
2017-04-13 15:41   ` Jan Beulich
2017-04-13 16:46     ` Boris Ostrovsky
2017-04-03 16:50 ` [PATCH v2 6/9] spinlock: Introduce spin_lock_cb() Boris Ostrovsky
2017-04-13 15:46   ` Jan Beulich
2017-04-13 16:55     ` Boris Ostrovsky
2017-04-18  6:49       ` Jan Beulich
2017-04-18 12:32         ` Boris Ostrovsky
2017-04-18 12:43           ` Jan Beulich
2017-04-18 13:14             ` Boris Ostrovsky
2017-04-03 16:50 ` [PATCH v2 7/9] mm: Keep pages available for allocation while scrubbing Boris Ostrovsky
2017-04-13 15:59   ` Jan Beulich
2017-04-03 16:50 ` [PATCH v2 8/9] mm: Print number of unscrubbed pages in 'H' debug handler Boris Ostrovsky
2017-04-03 16:50 ` [PATCH v2 9/9] mm: Make sure pages are scrubbed Boris Ostrovsky
2017-04-04 15:21 ` [PATCH v2 0/9] Memory scrubbing from idle loop George Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=64f16622-6614-1ef5-d232-98d2c9c8326d@oracle.com \
    --to=boris.ostrovsky@oracle.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=tim@xen.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.