Re: [Xen-devel] ns16550.c's poll_port variable

[Keir Fraser <keir.xen@xxxxxxxxx>]

On 04/05/2012 10:12, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:

>>>> On 04.05.12 at 10:25, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
>> On 04/05/2012 09:18, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>>> does this really need to be a per-CPU variable? Can't a timer run only
>>> once at a time on the entire system (the more that it gets re-armed only
>>> at the end of the poll function, whereas the variable is consumed at the
>>> start), and hence the variable can be a simple one? Or else, what
>>> subtlety am I overlooking?
>> 
>> We set up a timer per initialised uart. There can be more than one (although
>> granted it is rare).
> 
> Is that actually useful? console.c can't really use more than one at a
> time (for there being a single sercon_handle), so perhaps it would be
> a good thing to avoid the setup for those that aren't actively used,
> e.g. by not calling ->init_postirq() for other than the used one?
> 
> Oh, wait, with crash_debug there can be a second call to
> serial_parse_handle(), so in that case serial console and gdb stub
> may run through different ports. With crash_debug off by default,
> wouldn't it make sense to optimize for that common case, so that
> specifying both "com1=" and "com2=" on the command line wouldn't
> needlessly consume resources (as serial_parse_handle() can easily
> tag which ports it got called for)? Or would you rather take the
> position of expecting people to remove unnecessary command line
> options, or live with them having side effects?

I'm unclear on exactly what you want to optimise away? Certainly the 8 bytes
per CPU of the poll_port variable isn't worth much optimising effort.

 -- Keir

> Jan
> 



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