mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Cliff Wickman <cpw@sgi.com>
Cc: linux-kernel@vger.kernel.org, the arch/x86 maintainers <x86@kernel.org>
Subject: Re: [PATCHv4] SGI UV: TLB shootdown using broadcast assist unit
Date: Thu, 12 Jun 2008 15:11:42 +0200	[thread overview]
Message-ID: <20080612131142.GA30686@elte.hu> (raw)
In-Reply-To: <E1K6lqI-0006pX-JQ@eag09.americas.sgi.com>


* Cliff Wickman <cpw@sgi.com> wrote:

> +ENTRY(uv_bau_message_intr1)
> +	apicinterrupt 220,uv_bau_message_interrupt
> +END(uv_bau_message_intr1)

style: we try to add a single space after commas, to make it visually 
less crowded.

> @@ -162,6 +164,9 @@ void native_flush_tlb_others(const cpuma
>  	union smp_flush_state *f;
>  	cpumask_t cpumask = *cpumaskp;
>  
> +	if (is_uv_system() && uv_flush_tlb_others(&cpumask, mm, va))
> +		return;

since you basically hook into this function and replace it, wouldnt it 
make more sense instead to override the flush_tlb_others callback in 
paravirt_ops? That way common code is not affected.

> +char *status_table[] = {
> +	"IDLE",
> +	"ACTIVE",
> +	"DESTINATION TIMEOUT",
> +	"SOURCE TIMEOUT"
> +};
> +
> +DEFINE_PER_CPU(struct ptc_stats, ptcstats);
> +DEFINE_PER_CPU(struct bau_control, bau_control);

shouldnt these be static too?

> +	if (msp)
> +		msp->seen_by.bits = 0;
> +	uv_write_local_mmr(UVH_LB_BAU_INTD_SOFTWARE_ACKNOWLEDGE_ALIAS, dw);
> +	return;
> +}

return is not needed at the end of void functions. (there are many other 
similar incidents in the whole file)

> +	this_cpu_mask = (unsigned long)1 << cpu;

why not 1UL?

> +	sender = smp_processor_id();
> +	for (i = 0; i < (sizeof(struct bau_target_nodemask) * BITSPERBYTE); i++) {
> +	     i++) {
> +		if (!bau_node_isset(i, distribution))
> +			continue;
> +		bau_tablesp = uv_bau_table_bases[i];
> +		for (msg = bau_tablesp->va_queue_first, j = 0;
> +		     j < DESTINATION_PAYLOAD_QUEUE_SIZE; msg++, j++) {
> +			if ((msg->sending_cpu == sender) &&
> +			    (!msg->replied_to)) {
> +				msp = bau_tablesp->msg_statuses + j;
> +				printk(KERN_DEBUG
> +				"blade %d: address:%#lx %d of %d, not cpu(s): ",
> +				       i, msg->address,
> +				       msg->acknowledge_count,
> +				       msg->number_of_cpus);
> +				for (k = 0; k < msg->number_of_cpus;
> +				     k++) {
> +					if (!((long)1 << k & msp->
> +					      seen_by.bits)) {
> +						count++;
> +						printk("%d ", k);
> +					}
> +				}
> +				printk("\n");

why not split the iterator into a helper function? That would avoid all 
these line length artifacts as well. Also, decrease constant name 
length.

> +int uv_flush_send_and_wait(int cpu, int this_blade,
> +	struct bau_activation_descriptor *bau_desc, cpumask_t *cpumaskp)

'struct bau_activation_descriptor' is too long of a name (and that 
uglifies many prototypes) - why not use 'struct bau_desc'

> +	time1 = get_cycles();
> +	do {
> +		tries++;
> +		index = ((unsigned long)
> +			1 << UVH_LB_BAU_SB_ACTIVATION_CONTROL_PUSH_SHFT) | cpu;
> +		uv_write_local_mmr(UVH_LB_BAU_SB_ACTIVATION_CONTROL, index);
> +		completion_status = uv_wait_completion(bau_desc, mmr_offset,
> +					right_shift);
> +	} while (completion_status == FLUSH_RETRY);
> +	time2 = get_cycles();

is get_cycles() guaranteed to be stable on UV platforms? No cpufreq?

> +	pqp = __get_cpu_var(bau_control).va_queue_first;
> +	msg = __get_cpu_var(bau_control).bau_msg_head;
> +	while (msg->sw_ack_vector) {
> +		count++;
> +		fw = msg->sw_ack_vector;
> +		msg_slot = msg - pqp;
> +		sw_ack_slot = ffs(fw) - 1;
> +
> +		uv_bau_process_message(msg, msg_slot, sw_ack_slot);
> +
> +		msg++;
> +		if (msg > __get_cpu_var(bau_control).va_queue_last)
> +			msg = __get_cpu_var(bau_control).va_queue_first;
> +		__get_cpu_var(bau_control).bau_msg_head = msg;

many repetitive __get_cpu_var(bau_control) instances - put that into a 
helper variable instead, that makes it all much more readable.

> +static void uv_ptc_seq_stop(struct seq_file *file, void *data)
> +{
> +}

i think a NULL seq_stop will achieve a NOP. (not sure)

> +static const struct seq_operations uv_ptc_seq_ops = {
> +	.start	= uv_ptc_seq_start,
> +	.next	= uv_ptc_seq_next,
> +	.stop	= uv_ptc_seq_stop,
> +	.show	= uv_ptc_seq_show
> +};

small nit, we try to keep vertical alignment consistent across files, 
i.e.:

> +static const struct seq_operations uv_ptc_seq_ops = {
> +	.start		= uv_ptc_seq_start,
> +	.next		= uv_ptc_seq_next,
> +	.stop		= uv_ptc_seq_stop,
> +	.show		= uv_ptc_seq_show
> +};

> +	if (!proc_mkdir("sgi_uv", NULL))
> +		return -EINVAL;
> +
> +	proc_uv_ptc = create_proc_entry(UV_PTC_BASENAME, 0444, NULL);
> +	if (!proc_uv_ptc) {
> +		printk(KERN_ERR "unable to create %s proc entry\n",
> +		       UV_PTC_BASENAME);
> +		return -EINVAL;
> +	}

this failure branch will leak the sgi_uv directory.

> +	bau_tablesp =
> +	    kmalloc_node(sizeof(struct bau_control), GFP_KERNEL, node);
> +	if (!bau_tablesp)
> +		BUG();

use BUG_ON(). (in other instances as well in this same file)

> +	for (i = 0, ip = bau_tablesp->watching;
> +	     i < DESTINATION_PAYLOAD_QUEUE_SIZE; i++, ip++) {
> +		*ip = 0;
> +	}

this iteration could avoid the linebreak via intelligent shrinking of 
overlong symbols:

> +	for (i = 0, ip = bau_tablesp->watching; i < BAU_QUEUE_SIZE; i++, ip++)
> +		*ip = 0;

(similar things in other places as well)

	Ingo

      parent reply	other threads:[~2008-06-12 13:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-12 12:23 Cliff Wickman
2008-06-12 12:35 ` Nick Piggin
2008-06-12 12:56   ` Cliff Wickman
2008-06-12 13:18     ` Nick Piggin
2008-06-12 14:28       ` Cliff Wickman
2008-06-12 13:11 ` Ingo Molnar [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080612131142.GA30686@elte.hu \
    --to=mingo@elte.hu \
    --cc=cpw@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®