Re: [Publicity] Blog Czar update, week of July 22

[Roger Pau Monnà <roger.pau@xxxxxxxxxx>]

On 30/07/13 23:27, Dario Faggioli wrote:
> On mar, 2013-07-30 at 17:50 +0200, Roger Pau Monnà wrote:
>>> Also, if it's not too complicated, I would add a sentence explaining why
>>> the indirect descriptors approach is the best of all.
>>
>> The next paragraph explains why I think indirect descriptors are
>> probably the best approach, I'm not sure it's a good idea to add the
>> same to this one.
>>
> I saw that, and I'm not asking to neither move it nor to repeat it here.
> The point is you're saying indirect descriptors "it allows us to scale
> the maximum amount of data a request can contain, and modern storage
> devices tend to like big requests", but, AFAICT, also the two previous
> proposal achieved something similar (or at least were meant at that),
> isn't it? So, I was thinking whether it was worth mentioning quickly why
> indirect descriptors was the best among all three in improving the
> request size/throughput.

I've tried to expand a little bit the paragraph providing more detailed
information about each of the previous proposals, and a final note on
why indirect descriptors should be better. Basically they allow for more
outstanding IO if pushed to the limit.

>>> "in order to provide a good balance between memory usage and disk
>>> throughput" --> Mmm... sorry, can you help me understand what the issue
>>> is here: is the problem that you may occupy 512MB of Dom0/driver
>>> domain's memory per each guest (or is that even more)? Also, is that
>>> memory freed after the spike of disk activity that got the ring filled,
>>> or it just stay there forever?
>>
>> All the memory used by blkfront is allocated during boot, if we had to
>> allocate it when processing the requests we will have to use GFP_ATOMIC
>> (we are holding the queue spinlock while processing the request), which
>> can easily fail because it uses the emergency memory pool which is quite
>> small. So yes, memory is never freed.
>>
> Ok, I thought about something similar but couldn't tell for sure. Well,
> I now wonder (it's actually the reason why I asked) whether it would be
> nice to say something about this in the post. I don't have a strong
> opinion on this, though... I guess I'll let you decide, if you think
> it's already clear enough, or that it's not that important to specify in
> greater details, I'm fine with that. :-)

I think the blog post already contains a lot of very technical
information, adding more detailed stuff about memory utilization is just
going to make it even harder to read for people not involved in kernel
programming.

> I was about to suggest to publish this tomorrow or on Thursday, but then
> saw Lars' e-mail... Let's talk about this tomorrow...

I don't have any problem in postponing the publication, but I start my
holidays on Friday so I'm not sure if I will be able to answer many
comments (in case they arise) if it's published next week.


_______________________________________________
Publicity mailing list
Publicity@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity