From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: ns16550.c's poll_port variable Date: Fri, 04 May 2012 10:40:28 +0100 Message-ID: References: <4FA3B9B602000078000818E5@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4FA3B9B602000078000818E5@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On 04/05/2012 10:12, "Jan Beulich" wrote: >>>> On 04.05.12 at 10:25, Keir Fraser wrote: >> On 04/05/2012 09:18, "Jan Beulich" 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 >