[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Ymf69iLnB9sJaej0@infradead.org>
Date: Tue, 26 Apr 2022 07:00:22 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Donghai Qiao <dqiao@...hat.com>
Cc: akpm@...ux-foundation.org, sfr@...b.auug.org.au, arnd@...db.de,
peterz@...radead.org, heying24@...wei.com,
andriy.shevchenko@...ux.intel.com, axboe@...nel.dk,
rdunlap@...radead.org, tglx@...utronix.de, gor@...ux.ibm.com,
donghai.w.qiao@...il.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 00/11] smp: cross CPU call interface
On Fri, Apr 22, 2022 at 04:00:29PM -0400, Donghai Qiao wrote:
> The motivation of submitting this patch set is intended to make the
> existing cross CPU call mechanism become a bit more formal interface
> and more friendly to the kernel developers.
As far as I can tell it mostly does the reverse. The new interfaces
are a lot more verbose for no good reason. E.g. this is a common
pattern:
- on_each_cpu(common_shutdown_1, &args, 0);
+ smp_call(SMP_CALL_ALL, common_shutdown_1, &args, SMP_CALL_TYPE_ASYNC);
or this:
- smp_call_function_single(boot_cpuid, do_remote_read, &x, 1);
+ smp_call(boot_cpuid, do_remote_read, &x, SMP_CALL_TYPE_SYNC);
The old interface more or less made some sense. The new one is just a mess.
> Patch 1: The smp cross call related structures and definitions are
> consolidated from smp.c smp_types.h to smp.h. As a result, smp_types.h
> is deleted from the source tree.
And a lot of definitions that used to be private are not public.
Powered by blists - more mailing lists