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

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

>>> 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().


Xen-devel mailing list



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