Re: [PATCH] arch/sparc: Measure receiver forward progress to avoid send mondo timeout

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

 



From: Jane Chu <jane.chu@xxxxxxxxxx>
Date: Wed, 28 Jun 2017 15:02:26 -0600

>  static void hypervisor_xcall_deliver(struct trap_per_cpu *tb, int cnt)
>  {
> -	int retries, this_cpu, prev_sent, i, saw_cpu_error;
> +	int retries, this_cpu, prev_sent, i, rem;
> +	uint16_t first_cpu = 0xffff;
> +	unsigned long xc_rcvd = 0;
> +	int usec_wait = cnt * 2;
>  	unsigned long status;
> +	int ecpuerror_id = 0;
> +	int enocpu_id = 0;
>  	u16 *cpu_list;
> +	uint16_t cpu;

As you can see at the variable declarations around the ones you are
adding, "u16" is the appropriate type to use.  "uint16_t" is not.

So my concern about this patch is that in my mind, getting into a
state where a cpu is looping and doing nothing but handling mondos
is a bug.

That cpu is making no progress in it's execution stream, and that's
problematic.

I'd rather we attack the issue that gets into this situation in the
first place.

It's because we don't optimize large amounts of page TLB flushes
properly.

Firstly, we don't have a way to pass the array of pages to flush.
That would cut down the mondos by orders of magnitude.

We also could have a cutoff where we do a full MM flush instead
of flushing individual pages.

I bet if you implemented these two things, it would not only
make the mondo timeouts go away, it with make cpus actually
make forward progress in their instruction stream rather than
looping like crazy processing mondos.

Thanks.

--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Kernel Development]     [DCCP]     [Linux ARM Development]     [Linux]     [Photo]     [Yosemite Help]     [Linux ARM Kernel]     [Linux SCSI]     [Linux x86_64]     [Linux Hams]

  Powered by Linux