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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.05.12 at 11:40, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> 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.

Certainly not (and as you say they are actually needed, even if
only rarely). But the pointlessly running timer(s) might be, as might
the buffer(s) set up via serial_async_transmit().

Jan


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