xen-devel.lists.xenproject.org archive mirror
 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 v6 1/8] mm: Place unscrubbed pages at the end of pagelist
Date: Mon, 7 Aug 2017 10:55:33 -0400	[thread overview]
Message-ID: <097911fd-1912-fd81-77c9-d48cdfd5e43b@oracle.com> (raw)
In-Reply-To: <59887B16020000780010396C@prv-mh.provo.novell.com>

On 08/07/2017 10:37 AM, Jan Beulich wrote:
>>>>> Boris Ostrovsky <boris.ostrovsky@oracle.com> 08/07/17 4:16 PM >>>
>> On 08/06/2017 01:41 PM, Jan Beulich wrote:
>>>>>> Boris Ostrovsky <boris.ostrovsky@oracle.com> 08/04/17 7:03 PM >>>
>>>> +                /* See if any of the pages indeed need scrubbing. */
>>>> +                if ( first_dirty != INVALID_DIRTY_IDX )
>>>> +                {
>>>> +                    if ( (1U << cur_order) > first_dirty )
>>>> +                    {
>>>> +                        for ( i = first_dirty ; i < (1U << cur_order); i++ )
>>>> +                            if ( test_bit(_PGC_need_scrub,
>>>> +                                          &cur_head[i].count_info) )
>>>> +                            {
>>>> +                                idx = i;
>>>> +                                break;
>>>> +                            }
>>> Why again do you need to look through all the pages here, rather than
>>> simply marking the chunks as needing scrubbing simply based on first_dirty?
>>> It seems to me that I've asked this before, which is a good indication that
>>> such special behavior would better have a comment attached.
>> We want to make sure that there are in fact dirty pages in the
>> (sub-)buddy: first_dirty is only a hint there *may be* some.
> But why is that needed? Iirc you don't go to such length when splitting a
> buddy during allocation.

I felt that allocation is more time-critical and so I decided against
trying to be "neat" as far as tracking dirty pages exactly.

-boris

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

  reply	other threads:[~2017-08-07 14:55 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-04 17:05 [PATCH v6 0/8] Memory scrubbing from idle loop Boris Ostrovsky
2017-08-04 17:05 ` [PATCH v6 1/8] mm: Place unscrubbed pages at the end of pagelist Boris Ostrovsky
2017-08-06 17:41   ` Jan Beulich
2017-08-07 14:12     ` Boris Ostrovsky
2017-08-07 14:37       ` Jan Beulich
2017-08-07 14:55         ` Boris Ostrovsky [this message]
2017-08-07 15:28           ` Jan Beulich
2017-08-07 10:45   ` Julien Grall
2017-08-07 14:46     ` Boris Ostrovsky
2017-08-07 15:23       ` Julien Grall
2017-08-07 16:57         ` Boris Ostrovsky
2017-08-07 17:01           ` Julien Grall
2017-08-07 17:20             ` Boris Ostrovsky
2017-08-04 17:05 ` [PATCH v6 2/8] mm: Extract allocation loop from alloc_heap_pages() Boris Ostrovsky
2017-08-06 17:42   ` Jan Beulich
2017-08-04 17:05 ` [PATCH v6 3/8] mm: Scrub pages in alloc_heap_pages() if needed Boris Ostrovsky
2017-08-04 17:05 ` [PATCH v6 4/8] mm: Scrub memory from idle loop Boris Ostrovsky
2017-08-07  7:29   ` Jan Beulich
2017-08-07 14:05   ` Dario Faggioli
2017-08-04 17:05 ` [PATCH v6 5/8] spinlock: Introduce spin_lock_cb() Boris Ostrovsky
2017-08-07  7:32   ` Jan Beulich
2017-08-04 17:05 ` [PATCH v6 6/8] mm: Keep heap accessible to others while scrubbing Boris Ostrovsky
2017-08-07  7:50   ` Jan Beulich
2017-08-04 17:05 ` [PATCH v6 7/8] mm: Print number of unscrubbed pages in 'H' debug handler Boris Ostrovsky
2017-08-04 17:05 ` [PATCH v6 8/8] mm: Make sure pages are scrubbed Boris Ostrovsky

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=097911fd-1912-fd81-77c9-d48cdfd5e43b@oracle.com \
    --to=boris.ostrovsky@oracle.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).