>>> On 28.02.11 at 12:13, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> On Mon, 2011-02-28 at 10:55 +0000, Jan Beulich wrote:
>> >>> On 28.02.11 at 11:06, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>> > This is not the sort of thing which changes dynamically across the
>> > lifetime of a device, is it? In which case it seems like the sort of
>> > information which the backend could communicate to the frontend via
>> > xenbus at start of day. e.g. take a look at how the sector-size is
>> > passed through xenbus.
>> >
>> > It should be trivial to add this in a compatible manner since the
>> > frontend can just do what it does today if the nodes are missing and the
>> > backend wouldn't rely on the frontend doing anything useful with the
>> > information anyway.
>>
>> Am I right in understanding that these numbers aren't used by
>> the block layer itself at all, but just get provided to userspace for
>> whatever optimization it can do?
>>
>> Confused, Jan
>
> I had inferred from Adi's bringing them up that the kernel would
> actually use them in some way, but I don't actually know if that's the
> case...
>
>> In that case, I can't really see
>> how passing through these values can really help general
>> performance (i.e. for apps not paying attention to these values).
>
> Even their utility is only if userspace explicitly makes use of them
> they are just as useful in a Xen domU as they are in a non-Xen system,
> so why would we not plumb them through?
Plumbing through can be easily done, indeed, but the question
is if that gets us any performance improvement. If these are only
for allowing user mode optimizations, then maybe. If they're to
control kernel behavior, then the 11-pages-per-request limitation
of the blkif protocol would likely make this exercise pretty pointless
I would think.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home