From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v5 7/8] xen: arm: use superpages in p2m when pages are suitably aligned Date: Thu, 10 Jul 2014 13:44:30 +0100 Message-ID: <53BE8AAE.8080107@linaro.org> References: <1404907608.16789.18.camel@kazak.uk.xensource.com> <1404907666-8594-7-git-send-email-ian.campbell@citrix.com> <53BD6D94.7010108@linaro.org> <1404925873.26217.13.camel@hastur.hellion.org.uk> <53BE6C99.9070806@linaro.org> <1404991072.32404.39.camel@hastur.hellion.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1404991072.32404.39.camel@hastur.hellion.org.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: stefano.stabellini@eu.citrix.com, tim@xen.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 10/07/14 12:17, Ian Campbell wrote: > On Thu, 2014-07-10 at 11:36 +0100, Julien Grall wrote: >> >> On 09/07/14 18:11, Ian Campbell wrote: >>> On Wed, 2014-07-09 at 17:28 +0100, Julien Grall wrote: >>>>> + /* >>>>> + * could flush up to the next boundary, but would need to be >>>>> + * careful about preemption, so just do one page now and loop. >>>> >>>> At the first glance I though this code didn't handle correctly superpage >>>> flush. It took me several minutes to understand that you rely >>>> P2M_ONE_PROGRESS{,_NOP} to do the job for you. >>>> >>>> Can you explain this trick in the commit message? >>> >>> That's what the existing comment which you've quoted is attempting to >>> explain. Is it not clear enough? Can you suggest an improvement? >>> >>> Would "up to the next superpage boundary ... do one 4K page now and >>> loop" suffice? >> >> I think the most confusing word is "loop". I was waiting for see a >> "real" loop below. >> >> I would explain that the outer function taking care of the loop. > > OK. > > * could flush up to the next superpage boundary, but would need to be > * careful about preemption, so just do one 4K page now and return > * P2M_ONE_PROGRESS so that the caller will continue to loop over the > * rest of the range. > > ? It looks better for me. Thanks, -- Julien Grall