mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bagas Sanjaya <bagasdotme@gmail.com>
To: "Shi-Wu, Lo(Gmail)" <shiwulo@gmail.com>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
	Waiman Long <longman@redhat.com>,
	Boqun Feng <boqun.feng@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Mel Gorman <mgorman@suse.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Theodore Ts'o <tytso@mit.edu>
Subject: Re: A new spinlock for multicore (>16) platform
Date: Mon, 15 Jul 2024 06:45:16 +0700	[thread overview]
Message-ID: <ZpRjDDKGq1F4cSBr@archie.me> (raw)
In-Reply-To: <CAOpXEOwh6r0Fo_5hgXET6gGHTUxTdE1aDkp_K0ga8BwGSDMX+A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3042 bytes --]

On Mon, Jul 15, 2024 at 01:07:40AM +0800, Shi-Wu, Lo(Gmail) wrote:
> Dear Linux Contributors,
> I am a Linux enthusiast from Taiwan, and I hope to contribute to the
> Linux kernel. We have developed a new spinlock method that has been
> validated on AMD 64-core and AMD 32-core processors. Compared to
> previous methods, this new method is optimized in the following areas:
> 
> Motivation and Approaches:
> 1. As the number of cores increases, there is a need for more refined
> optimization of the data transmission paths between cores.
> 2. Data transmission usually involves lock-unlock wrapping.
> 3. Performance improvement can be achieved using a shortest path
> approximation algorithm.
>    A detailed introduction to this method can be found in the following paper:
> https://www.usenix.org/conference/osdi23/presentation/lo
> 
> Our laboratory is currently developing a system that can apply the
> same optimization strategy to all multi-core processors. Below is our
> plan.
> 
> The New Method and Its Compatibility with qspinlock:
> 1. The default algorithm in the Linux kernel remains qspinlock.
> 2. A new file is created in /proc/routing_path, where a shortest path
> can be input, for example:
> sudo echo 1,2,3,4,16,17,18,19,5,6,7,8,11,12,13,14 > /proc/routing_path
> 3. After inputting the shortest path, the kernel switches to using the
> RON algorithm.
> 
> Expected Outcomes:
> According to our measurements on AMD 32-core and AMD 64-core
> processors, Google LevelDB can achieve a 3-4% speed improvement.
> 
> Comparison with Previous NUMA-aware algorithms:
> Compared to NUMA-aware results, since such systems may contain more
> than two processors, the communication cost between processors is much
> higher than the communication cost between cores (within the same
> processor). Our method focuses on multiple cores within a single
> processor, making it multicore-aware. If a NUMA-aware algorithm is
> used in a multicore environment, it is not as effective as a
> multicore-aware algorithm. (Please refer to the paper,
> https://www.usenix.org/conference/osdi23/presentation/lo)
> 
> Assistance Needed:
> I would like to understand if the Linux kernel community is interested
> in this new spinlock method. As a teacher, I cannot complete all the
> work by myself. Is anyone willing to collaborate with me on this
> project?
> 
> Sorry to bother you:
> I apologize for taking up so much of your time with this letter.
> Although I am quite old, this is the first time I feel that my
> research results are good enough to contribute to the Linux community.
> I have read the relevant documentation, and it made me realize that my
> time and abilities are insufficient to write the high-quality code
> required by the Linux community. Therefore, I ask for your guidance.

I can't really say about this topic (as I'm not subject-matter expert here),
so Cc: relevant maintainers.

Thanks!

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2024-07-14 23:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-14 17:07 Shi-Wu, Lo(Gmail)
2024-07-14 23:45 ` Bagas Sanjaya [this message]
2024-07-15  2:08   ` Waiman Long
2024-07-15 10:01     ` Shi-Wu, Lo(Gmail)
2024-07-15  9:54   ` Peter Zijlstra
2024-07-15 10:33     ` Shi-Wu, Lo(Gmail)
2024-07-16 18:10       ` Shi-Wu, Lo(Gmail)
2024-07-20  7:08         ` Bagas Sanjaya

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=ZpRjDDKGq1F4cSBr@archie.me \
    --to=bagasdotme@gmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=shiwulo@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=tytso@mit.edu \
    --cc=will@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®