On Wed, May 15, 2019 at 09:03:58AM +0100, Andrea Bolognani wrote:
> On Tue, 2019-05-14 at 13:14 -0700, Richard Henderson wrote:
> > On 5/14/19 9:03 AM, Andrea Bolognani wrote:
> > > On Tue, 2019-05-14 at 14:53 +0200, Andrew Jones wrote:
> > > > We already have sve-max-vq, so I'm not sure we want to rename it.
> > >
> > > Oh, I didn't realize that was the case. And of course it already
> > > takes a number of quadwords as argument, I suppose? That's pretty
> > > unfortunate :(
> > >
> > > Perhaps we could consider deprecating it in favor of a user-friendly
> > > variant that's actually suitable for regular humans, like the one I
> > > suggest above?
> >
> > Why is =4 less user-friendly than =512?
> >
> > I don't actually see "total bits in vector" as more user-friendly than
> > "number
> > of quadwords" when it comes to non-powers-of-2 like =7 vs =896 or =13 vs
> > =1664.
>
> I would wager most people are intimately familiar with bits, bytes
> and multiples due to having to work with them daily. Quadwords, not
> so much.
Generally I tend to agree. For kvmtool I leaned torward quadwords
purely because
16,32,48,64,80,96,112,128,144,160,176,192,208
is a big pain to type compared with
1,2,3,4,5,6,7,8,9,10,11,12,13
Even though I prefer to specify vector lengths in bytes everywhere else
in the Linux user API (precisely to avoid the confusion you object to).
This isn't finalised yet for kvmtool -- I need to rework the patches
and may not include it at all initially: kvmtool doesn't support
migration, which is the main usecase for being able to specify an exact
set of vector lengths AFAICT.
Since this is otherwise only useful for migration, experimentation or
machine-driven configuration, a bitmask
0x1fff
as some have suggested may well be a pragmatic alternative for kvmtool.
Cheers
---Dave
