On 10/08/17 12:40, Wei Liu wrote:
On Thu, Aug 10, 2017 at 01:29:04PM +0530, Bhupinder Thakur wrote:
On 9 August 2017 at 16:33, Wei Liu <wei.l...@citrix.com> wrote:
On Wed, Aug 09, 2017 at 04:28:14PM +0530, Bhupinder Thakur wrote:
Thanks for the testing.
On 8 August 2017 at 21:29, Julien Grall <julien.gr...@arm.com> wrote:
I gave another and I have a couple of comments.
Booting Linux with earlycon enabled take quite a while. I can see the
characters coming slower than on the minitel. It seems to be a bit better
after switching off the bootconsole. Overall Linux is taking ~20 times to
boot with pl011 vs HVC console.
I do agree that pl011 is emulated and therefore you have to trap after each
character. But 20 times sounds far too much.
I think this slowness could be due to ratelimiting of the pl011 events
in xenconosle. Currently, the rate limit is
set to 30 events per 200 msecs (see RATE_LIMIT_ALLOWANCE/RATE_LIMIT_PERIOD).
I increased the rate limit to 600 events (30 * 20) per 200 msecs. With
I see that the the find command is running faster and smoother.
Earlier the find output would be jerky.
Please consider batching the events instead of bumping the limit.
If I try to batch the events then it may delay per character
processing (if no further characters are coming) since we will wait
for more events to come to batch them together. By keeping the rate
limit high, it is ensured that it can handle large burst of events. If
there is sporadic data then the rate limit is not hit.
But do you really need to send an event for every character (that's my
reading of your patch, please correct me if I'm wrong)? Suppose you have
a buffer you can send one event when the buffer is processed.
I am not sure what you mean by buffer here. The interface with the guest
is a single data register. So characters are written one by one.
I am thinking of making the rate limit configuration per console.
There is the question why vuart is special with regard to other types of
If something is mandated by the spec it should be specifically called
out to justify the decision to bump the rate limit.
I might have other ideas how to improve the speed. I will answer on
Xen-devel mailing list