[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 02/27] ARM: GICv3: allocate LPI pending and property table



On Fri, 24 Mar 2017, Julien Grall wrote:
> Hi Andre,
> 
> On 03/23/2017 06:21 PM, Andre Przywara wrote:
> > Hi,
> > 
> > On 23/03/17 18:01, Stefano Stabellini wrote:
> > > On Thu, 23 Mar 2017, Julien Grall wrote:
> > > > Hi Stefano,
> > > > 
> > > > On 23/03/17 17:45, Stefano Stabellini wrote:
> > > > > On Thu, 23 Mar 2017, Julien Grall wrote:
> > > > > > > So as I mentioned before, I am happy to loose the Kconfig option,
> > > > > > > but
> > > > > > > then we need some sensible default value. In our case we could be
> > > > > > > cheeky
> > > > > > > here for now and just use the Linux value, because a Linux Dom0
> > > > > > > would be
> > > > > > > the only user. But that doesn't sound very future proof, though
> > > > > > > this may
> > > > > > > not matter for 4.9.
> > > > > > 
> > > > > > I don't think we need a sensible default value and IHMO there is
> > > > > > none. I
> > > > > > would
> > > > > > left the user to decide the exact number.
> > > > > 
> > > > > In that case, the command line parameter becomes mandatory: we need to
> > > > > force the user to specify it as we do for dom0_mem today.
> > > > 
> > > > Not really. We should use the hardware value by default. If a user
> > > > thinks the
> > > > number allocated is too big for his use case, then it can limit using
> > > > the
> > > > command line.
> > > > 
> > > > Anyway, I will not oppose to make this command option mandatory when ITS
> > > > is in
> > > > use.
> > > 
> > > Andre wrote:
> > > 
> > >   Any redistributor supporting 32 bits worth of LPIs would lead to a
> > >   4GB property table and 512MB pending table allocation.
> > > 
> > > Let's assume that such scenario is realistic (if it is not, then this
> > > discussion is fruitless), in this case the user most surely is not going
> > > to want to use the hardware provided value. But how can she knows it?
> > > How can she find out that she is wasting too much memory on her system?
> > > Is there an easy and obvious way to know?
> > > 
> > > She could find out if Xen printed a big warning such as:
> > > 
> > >   USING 4G OF MEMORY FOR ITS PROPTABLE, CONSIDER PASSING max_lpi_bits to
> > > XEN
> > > 
> > > but to do that, we need a threshold value in Xen, above which the
> > > hypervisor prints the warning. But if we have a threshold value in Xen,
> > > then we might as well consider making it the default ceiling: Xen uses
> > > the hardware provided value, unless it's greater than threshold, in that
> > > case it uses threshold and prints a warning, for example:
> > > 
> > >   LIMITING ITS PROPTABLE MEMORY TO 1G, CHANGE IT WITH max_lpi_bits
> > > PARAMETER
> > > 
> > > 
> > > Does it make sense?
> > 
> > Yes, that is exactly what I was after.
> > In contrast to the number of device IDs I think the number of LPI bits
> > is _not_ a value that software should use directly, it's more a limit,
> > actually a GICv3 implementation choice (how wide the LPI ID fields
> > internally are, for instance).
> > 
> > So do we want to limit to 1GB and warn starting at 256MB?
> 
> I think Stefano was suggesting to make the command line mandatory.

Either way works, but the idea is that the user should not be surprised
by the amount of memory utilized because either

1) she chose max_lpi_bits
2) Xen printed a WARNING at boot impossible to miss

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.