Re: [FYI][PATCH] tracing/treewide: Remove second parameter of __assign_str()

On Thu, 14 Mar 2024 09:57:57 -0700 Alison Schofield wrote: > On Fri, Feb 23, 2024 at 12:56:34PM -0500, Steven Rostedt wrote: > > From: "Steven Rostedt (Google)" > > > > [ > >This is a treewide change. I will likely re-create this patch again in > >the second week of the merge window of

Re: [FYI][PATCH] tracing/treewide: Remove second parameter of __assign_str()

On Fri, Feb 23, 2024 at 12:56:34PM -0500, Steven Rostedt wrote: > From: "Steven Rostedt (Google)" > > [ >This is a treewide change. I will likely re-create this patch again in >the second week of the merge window of v6.9 and submit it then. Hoping >to keep the conflicts that it will

Re: [FYI][PATCH] tracing/treewide: Remove second parameter of __assign_str()

On Fri, 23 Feb 2024 13:46:53 -0500 Steven Rostedt wrote: > Now one thing I could do is to not remove the parameter, but just add: > > WARN_ON_ONCE((src) != __data_offsets->item##_ptr_); > > in the __assign_str() macro to make sure that it's still the same that is > assigned. But I'm not

Re: [FYI][PATCH] tracing/treewide: Remove second parameter of __assign_str()

On Fri, 23 Feb 2024 14:50:49 -0500 Kent Overstreet wrote: > Tangentially related though, what would make me really happy is if we > could create the string with in the TP__fast_assign() section. I have to > have a bunch of annoying wrappers right now because the string length > has to be known

Re: [FYI][PATCH] tracing/treewide: Remove second parameter of __assign_str()

On Fri, Feb 23, 2024 at 01:46:53PM -0500, Steven Rostedt wrote: > On Fri, 23 Feb 2024 10:30:45 -0800 > Jeff Johnson wrote: > > > On 2/23/2024 9:56 AM, Steven Rostedt wrote: > > > From: "Steven Rostedt (Google)" > > > > > > [ > > >This is a treewide change. I will likely re-create this

Re: [FYI][PATCH] tracing/treewide: Remove second parameter of __assign_str()

On Fri, 23 Feb 2024 10:30:45 -0800 Jeff Johnson wrote: > On 2/23/2024 9:56 AM, Steven Rostedt wrote: > > From: "Steven Rostedt (Google)" > > > > [ > >This is a treewide change. I will likely re-create this patch again in > >the second week of the merge window of v6.9 and submit it

Re: [FYI][PATCH] tracing/treewide: Remove second parameter of __assign_str()

On 2/23/2024 9:56 AM, Steven Rostedt wrote: > From: "Steven Rostedt (Google)" > > [ >This is a treewide change. I will likely re-create this patch again in >the second week of the merge window of v6.9 and submit it then. Hoping >to keep the conflicts that it will cause to a minimum.

Re: [FYI][PATCH] tracing/treewide: Remove second parameter of __assign_str()

On Fri, 23 Feb 2024 12:56:34 -0500 Steven Rostedt wrote: > Note, the same updates will need to be done for: > > __assign_str_len() > __assign_rel_str() > __assign_rel_str_len() Correction: The below macros do not pass in their source to the entry macros, so they will not need to be

[PATCH 5.11 029/254] cifs: change noisy error message to FYI

wait for mid zzz cmd: c because some processes that were performing statfs(2) on the share had been interrupted due to their automount setup when certain users logged in and out. Change it to FYI as they should be mostly informative rather than error messages. Signed-off-by: Paulo Alcantara (SUSE

[PATCH 5.10 030/221] cifs: change noisy error message to FYI

wait for mid zzz cmd: c because some processes that were performing statfs(2) on the share had been interrupted due to their automount setup when certain users logged in and out. Change it to FYI as they should be mostly informative rather than error messages. Signed-off-by: Paulo Alcantara (SUSE

[PATCH 5.4 023/111] cifs: change noisy error message to FYI

wait for mid zzz cmd: c because some processes that were performing statfs(2) on the share had been interrupted due to their automount setup when certain users logged in and out. Change it to FYI as they should be mostly informative rather than error messages. Signed-off-by: Paulo Alcantara (SUSE

Re: [Ksummit-discuss] FYI & RFC: obsoleting reporting-bugs and making reporting-issues official

On 26.03.21 09:59, Greg KH wrote: > On Fri, Mar 26, 2021 at 07:13:09AM +0100, Thorsten Leemhuis wrote: >> >> Lo! Since a few months mainline in >> Documentation/admin-guide/reporting-issues.rst contains a text written >> to obsolete the good old reporting-bugs text. For now, the new document >>

Re: [Ksummit-discuss] FYI & RFC: obsoleting reporting-bugs and making reporting-issues official

On Fri, Mar 26, 2021 at 07:13:09AM +0100, Thorsten Leemhuis wrote: > > Lo! Since a few months mainline in > Documentation/admin-guide/reporting-issues.rst contains a text written > to obsolete the good old reporting-bugs text. For now, the new document > still contains a warning at the top that

FYI & RFC: obsoleting reporting-bugs and making reporting-issues official

Lo! Since a few months mainline in Documentation/admin-guide/reporting-issues.rst contains a text written to obsolete the good old reporting-bugs text. For now, the new document still contains a warning at the top that basically says "this is WIP". But I'd like to remove that warning and delete

[PATCH AUTOSEL 5.10 28/54] cifs: change noisy error message to FYI

wait for mid zzz cmd: c because some processes that were performing statfs(2) on the share had been interrupted due to their automount setup when certain users logged in and out. Change it to FYI as they should be mostly informative rather than error messages. Signed-off-by: Paulo Alcantara (SUSE

[PATCH AUTOSEL 5.4 22/37] cifs: change noisy error message to FYI

wait for mid zzz cmd: c because some processes that were performing statfs(2) on the share had been interrupted due to their automount setup when certain users logged in and out. Change it to FYI as they should be mostly informative rather than error messages. Signed-off-by: Paulo Alcantara (SUSE

[PATCH AUTOSEL 5.11 29/61] cifs: change noisy error message to FYI

wait for mid zzz cmd: c because some processes that were performing statfs(2) on the share had been interrupted due to their automount setup when certain users logged in and out. Change it to FYI as they should be mostly informative rather than error messages. Signed-off-by: Paulo Alcantara (SUSE

Re: [Intel-gfx] [FYI PATCH] i915: kvmgt: the KVM mmu_lock is now an rwlock

Hi Paolo, I love your patch! Yet something to improve: [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on linux/master drm-tip/drm-tip linus/master v5.11-rc6 next-20210125] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting

Re: [Intel-gfx] [FYI PATCH] i915: kvmgt: the KVM mmu_lock is now an rwlock

Hi Paolo, I love your patch! Yet something to improve: [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on linux/master drm-tip/drm-tip linus/master v5.11-rc6 next-20210125] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting

Re: [FYI PATCH] i915: kvmgt: the KVM mmu_lock is now an rwlock

On 2021.02.08 06:34:37 -0500, Paolo Bonzini wrote: > Adjust the KVMGT page tracking callbacks. > > Cc: Zhenyu Wang > Cc: Zhi Wang > Cc: intel-gvt-...@lists.freedesktop.org > Cc: intel-...@lists.freedesktop.org > Signed-off-by: Paolo Bonzini > --- Thanks for that! Acked-by: Zhenyu Wang >

[FYI PATCH] i915: kvmgt: the KVM mmu_lock is now an rwlock

Adjust the KVMGT page tracking callbacks. Cc: Zhenyu Wang Cc: Zhi Wang Cc: intel-gvt-...@lists.freedesktop.org Cc: intel-...@lists.freedesktop.org Signed-off-by: Paolo Bonzini --- drivers/gpu/drm/i915/gvt/kvmgt.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git

Re: FYI: PoC: Running 100000 processes in 5.3.18 (SLES15 SP2)

Hi! > > Just in case someone is interested: As a Proof-of-Concept I started 100 > thousand processes on a big machine (72 cores). It worked! > However starting those too more than 30 minutes, and top needs more than 30 > minutes to refresh ist display. Still, interactive input via SSH works

FYI: PoC: Running 100000 processes in 5.3.18 (SLES15 SP2)

Hi! Just in case someone is interested: As a Proof-of-Concept I started 100 thousand processes on a big machine (72 cores). It worked! However starting those too more than 30 minutes, and top needs more than 30 minutes to refresh ist display. Still, interactive input via SSH works nice, but

Re: [FYI] lm3532: right registration to work with LED-backlight

Hi Pavel, On 9/17/19 2:42 PM, Pavel Machek wrote: > Hi! > > +++ b/drivers/leds/leds-lm3532.c > @@ -629,7 +629,7 @@ static int lm3532_parse_node(struct lm3532_data *priv) > > lm3532_init_registers(led); > > - ret =

Re: [FYI] lm3532: right registration to work with LED-backlight

Hi! > >>> +++ b/drivers/leds/leds-lm3532.c > >>> @@ -629,7 +629,7 @@ static int lm3532_parse_node(struct lm3532_data *priv) > >>> > >>> lm3532_init_registers(led); > >>> > >>> - ret = devm_led_classdev_register(priv->dev, >led_dev); > >>> + ret =

Re: [FYI] lm3532: right registration to work with LED-backlight

On 9/8/19 10:03 AM, Pavel Machek wrote: > On Wed 2019-08-28 22:32:57, Jacek Anaszewski wrote: >> On 8/28/19 10:53 AM, Pavel Machek wrote: >>> Hi! >>> >>> Eventually, these will be needed. >>> >>> Best regards, >>> Pavel >>> >>> commit

Re: [FYI] lm3532: right registration to work with LED-backlight

On Wed 2019-08-28 22:32:57, Jacek Anaszewski wrote: > On 8/28/19 10:53 AM, Pavel Machek wrote: > > Hi! > > > > Eventually, these will be needed. > > > > Best regards, > > Pavel > > > > commit 38d956977a7d6cbdc811676f9b4033da7487e045 >

Re: [FYI] lm3532: right registration to work with LED-backlight

On 8/28/19 10:53 AM, Pavel Machek wrote: > Hi! > > Eventually, these will be needed. > > Best regards, > Pavel > > commit 38d956977a7d6cbdc811676f9b4033da7487e045 > Author: Pavel > Date: Wed Aug 7 12:43:52 2019 +0200 > > d4:

[FYI] lm3532: right registration to work with LED-backlight

Hi! Eventually, these will be needed. Best regards, Pavel commit 38d956977a7d6cbdc811676f9b4033da7487e045 Author: Pavel Date: Wed Aug 7 12:43:52 2019 +0200 d4: lm3532 needs to use right register function for backlight to

Re: Fyi

Hello linux-kernel@vger.kernel.org I am Karen Ngui by name got your details based on recommendations from LinkedIn 5 star marketers and its feels good to be part of your professional network. I sent you a proposal via email on the 10th of this month did you get it ? Do reply to my message

RE: FYI -ffreestanding shrinks kernel by 2% on x86_64

From: Ingo Molnar > Sent: 12 May 2019 10:32 ... > Has anyone investigated by any chance where the -ffreestanding space > savings come from mostly - is it mostly in cold paths, or does it make or > hot codepaths more efficient as well? > > If it's the latter then the kernel would be directly

Re: FYI -ffreestanding shrinks kernel by 2% on x86_64

On Sun, May 12, 2019 at 11:32:28AM +0200, Ingo Molnar wrote: > > * Alexey Dobriyan wrote: > > > On Sat, May 11, 2019 at 11:02:24PM +0300, Alexey Dobriyan wrote: > > > I compiled current F29 kernel config on x86_64 (5.0.13-200.fc29.x86_64) > > > with -ffreestanding. The results are interesting

Re: FYI -ffreestanding shrinks kernel by 2% on x86_64

* Alexey Dobriyan wrote: > On Sat, May 11, 2019 at 11:02:24PM +0300, Alexey Dobriyan wrote: > > I compiled current F29 kernel config on x86_64 (5.0.13-200.fc29.x86_64) > > with -ffreestanding. The results are interesting :^): > > > > add/remove: 30/22 grow/shrink: 1290/46867 up/down:

FYI -ffreestanding shrinks kernel by 2% on x86_64

On Sat, May 11, 2019 at 11:02:24PM +0300, Alexey Dobriyan wrote: > I compiled current F29 kernel config on x86_64 (5.0.13-200.fc29.x86_64) > with -ffreestanding. The results are interesting :^): > > add/remove: 30/22 grow/shrink: 1290/46867 up/down: 33658/-1778055 > (-1744397) >

FYI>

Sequel to your non response to my previous email, I am thus; re-sending this to you. I contacted you because a deceased client of mine left behind some funds in dormant account which I want you to assist in distributing. Regards, Andrew Smith

Re: FYI: Userland breakage caused by udev bind commit

On Mon, Dec 24, 2018 at 10:28:20AM -0800, Linus Torvalds wrote: > On Mon, Dec 24, 2018 at 10:13 AM Christian Brauner > wrote: > > > > So one possibility is to add a socket option for lib/kobject_uevent.c > > that can be set via setsockopt. We did something like this in netlink > > for strict

Re: FYI: Userland breakage caused by udev bind commit

On Mon, Dec 24, 2018 at 10:13 AM Christian Brauner wrote: > > So one possibility is to add a socket option for lib/kobject_uevent.c > that can be set via setsockopt. We did something like this in netlink > for strict property and header checking without breaking backwards > compatibility. I'd

Re: FYI: Userland breakage caused by udev bind commit

On Mon, Dec 24, 2018 at 10:06:54AM -0800, Linus Torvalds wrote: > On Mon, Dec 24, 2018 at 9:34 AM Dmitry Torokhov > wrote: > > > > Well, it appears that we can no longer extend uevent interface with new > > types of uevents, at least not until we go and fix up all > > udev-derivatives and give

Re: FYI: Userland breakage caused by udev bind commit

On Mon, Dec 24, 2018 at 9:34 AM Dmitry Torokhov wrote: > > Well, it appears that we can no longer extend uevent interface with new > types of uevents, at least not until we go and fix up all > udev-derivatives and give some time for things to settle. How about having the users "opt in" for new

Re: FYI: Userland breakage caused by udev bind commit

On Mon, Dec 24, 2018 at 11:54:07AM +0100, Greg KH wrote: > On Mon, Dec 24, 2018 at 11:15:34AM +0100, Gabriel C wrote: > > Am Mo., 24. Dez. 2018 um 10:17 Uhr schrieb Greg KH > > : > > > > > > On Mon, Dec 24, 2018 at 08:31:27AM +0100, Gabriel C wrote: > > > > Am So., 23. Dez. 2018 um 19:09 Uhr

Re: FYI: Userland breakage caused by udev bind commit

Am Mo., 24. Dez. 2018 um 11:54 Uhr schrieb Greg KH : > > On Mon, Dec 24, 2018 at 11:15:34AM +0100, Gabriel C wrote: > > Am Mo., 24. Dez. 2018 um 10:17 Uhr schrieb Greg KH > > : > > > > > > On Mon, Dec 24, 2018 at 08:31:27AM +0100, Gabriel C wrote: > > > > Am So., 23. Dez. 2018 um 19:09 Uhr

Re: FYI: Userland breakage caused by udev bind commit

On Mon, Dec 24, 2018 at 11:15:34AM +0100, Gabriel C wrote: > Am Mo., 24. Dez. 2018 um 10:17 Uhr schrieb Greg KH > : > > > > On Mon, Dec 24, 2018 at 08:31:27AM +0100, Gabriel C wrote: > > > Am So., 23. Dez. 2018 um 19:09 Uhr schrieb Dmitry Torokhov > > > : > > > > > > [ also added Linus to CC on

Re: FYI: Userland breakage caused by udev bind commit

Am Mo., 24. Dez. 2018 um 10:17 Uhr schrieb Dmitry Torokhov : > > On Mon, Dec 24, 2018 at 08:31:27AM +0100, Gabriel C wrote: > > Am So., 23. Dez. 2018 um 19:09 Uhr schrieb Dmitry Torokhov > > : > > > > [ also added Linus to CC on that one too ] > > > > > > On Sun, Dec 23, 2018 at 06:17:04PM +0100,

Re: FYI: Userland breakage caused by udev bind commit

Am Mo., 24. Dez. 2018 um 10:17 Uhr schrieb Greg KH : > > On Mon, Dec 24, 2018 at 08:31:27AM +0100, Gabriel C wrote: > > Am So., 23. Dez. 2018 um 19:09 Uhr schrieb Dmitry Torokhov > > : > > > > [ also added Linus to CC on that one too ] > > > > > > On Sun, Dec 23, 2018 at 06:17:04PM +0100,

Re: FYI: Userland breakage caused by udev bind commit

On Mon, Dec 24, 2018 at 01:22:57AM -0800, Dmitry Torokhov wrote: > On Mon, Dec 24, 2018 at 10:12:29AM +0100, Greg KH wrote: > > On Sun, Dec 23, 2018 at 05:49:54PM +0100, Marcus Meissner wrote: > > > Hi, > > > > > > I am the maintainer of libmtp and libgphoto2 > > > > > > Some months ago I was

Re: FYI: Userland breakage caused by udev bind commit

On Mon, Dec 24, 2018 at 10:12:29AM +0100, Greg KH wrote: > On Sun, Dec 23, 2018 at 05:49:54PM +0100, Marcus Meissner wrote: > > Hi, > > > > I am the maintainer of libmtp and libgphoto2 > > > > Some months ago I was made aware of this bug: > > https://bugs.kde.org/show_bug.cgi?id=387454 > >

Re: FYI: Userland breakage caused by udev bind commit

On Mon, Dec 24, 2018 at 08:31:27AM +0100, Gabriel C wrote: > Am So., 23. Dez. 2018 um 19:09 Uhr schrieb Dmitry Torokhov > : > > [ also added Linus to CC on that one too ] > > > > On Sun, Dec 23, 2018 at 06:17:04PM +0100, Christian Brauner wrote: > > > On Sun, Dec 23, 2018 at 05:49:54PM +0100,

Re: FYI: Userland breakage caused by udev bind commit

On Mon, Dec 24, 2018 at 08:31:27AM +0100, Gabriel C wrote: > Am So., 23. Dez. 2018 um 19:09 Uhr schrieb Dmitry Torokhov > : > > [ also added Linus to CC on that one too ] > > > > On Sun, Dec 23, 2018 at 06:17:04PM +0100, Christian Brauner wrote: > > > On Sun, Dec 23, 2018 at 05:49:54PM +0100,

Re: FYI: Userland breakage caused by udev bind commit

On Sun, Dec 23, 2018 at 05:49:54PM +0100, Marcus Meissner wrote: > Hi, > > I am the maintainer of libmtp and libgphoto2 > > Some months ago I was made aware of this bug: > https://bugs.kde.org/show_bug.cgi?id=387454 > > This was fallout identified to come from this kernel commit: > >

Re: FYI: Userland breakage caused by udev bind commit

Am So., 23. Dez. 2018 um 19:09 Uhr schrieb Dmitry Torokhov : [ also added Linus to CC on that one too ] > > On Sun, Dec 23, 2018 at 06:17:04PM +0100, Christian Brauner wrote: > > On Sun, Dec 23, 2018 at 05:49:54PM +0100, Marcus Meissner wrote: > > > Hi, > > > > > > I am the maintainer of libmtp

Re: FYI: Userland breakage caused by udev bind commit

On Sun, Dec 23, 2018 at 06:17:04PM +0100, Christian Brauner wrote: > On Sun, Dec 23, 2018 at 05:49:54PM +0100, Marcus Meissner wrote: > > Hi, > > > > I am the maintainer of libmtp and libgphoto2 > > > > Some months ago I was made aware of this bug: > >

Re: FYI: Userland breakage caused by udev bind commit

On Sun, Dec 23, 2018 at 05:49:54PM +0100, Marcus Meissner wrote: > Hi, > > I am the maintainer of libmtp and libgphoto2 > > Some months ago I was made aware of this bug: > https://bugs.kde.org/show_bug.cgi?id=387454 > > This was fallout identified to come from this kernel commit: > >

FYI: Userland breakage caused by udev bind commit

Hi, I am the maintainer of libmtp and libgphoto2 Some months ago I was made aware of this bug: https://bugs.kde.org/show_bug.cgi?id=387454 This was fallout identified to come from this kernel commit: commit 1455cf8dbfd06aa7651dcfccbadb7a093944ca65 Author: Dmitry

FYI, critical bug in rcutorture

Hello, David, So I have updated rcutorture to include need_resched()-protected calls to cond_resched() in a tight loop that includes an RCU read-side critical section on each pass. This loop runs for five seconds by default and complains bitterly if grace periods did not complete during that

FYI, critical bug in rcutorture

Hello, David, So I have updated rcutorture to include need_resched()-protected calls to cond_resched() in a tight loop that includes an RCU read-side critical section on each pass. This loop runs for five seconds by default and complains bitterly if grace periods did not complete during that

Re: [lkp-robot] [Kbuild] 050e9baa9d: netperf.Throughput_total_tps -5.6% regression (FYI)

On Thu, Jun 21, 2018 at 5:25 PM Huang, Ying wrote: > Do you have interest in some other comparison? No, I think the overhead of the strong stackprotector is a bit sad, but I assume it's because of the nasty code to load the stack canary from a cacheline that has absolutely nothing else in it.

Re: [lkp-robot] [Kbuild] 050e9baa9d: netperf.Throughput_total_tps -5.6% regression (FYI)

On Thu, Jun 21, 2018 at 5:25 PM Huang, Ying wrote: > Do you have interest in some other comparison? No, I think the overhead of the strong stackprotector is a bit sad, but I assume it's because of the nasty code to load the stack canary from a cacheline that has absolutely nothing else in it.

Re: [lkp-robot] [Kbuild] 050e9baa9d: netperf.Throughput_total_tps -5.6% regression (FYI)

Hi, Linus, Linus Torvalds writes: > On Thu, Jun 21, 2018 at 5:10 PM kernel test robot > wrote: >> >> FYI, we noticed a -5.6% regression of netperf.Throughput_total_tps >> due to commit 050e9b ("Kbuild: rename CC_STACKPROTECTOR[_STRONG] >> config variables&

Re: [lkp-robot] [Kbuild] 050e9baa9d: netperf.Throughput_total_tps -5.6% regression (FYI)

Hi, Linus, Linus Torvalds writes: > On Thu, Jun 21, 2018 at 5:10 PM kernel test robot > wrote: >> >> FYI, we noticed a -5.6% regression of netperf.Throughput_total_tps >> due to commit 050e9b ("Kbuild: rename CC_STACKPROTECTOR[_STRONG] >> config variables&

Re: [lkp-robot] [Kbuild] 050e9baa9d: netperf.Throughput_total_tps -5.6% regression (FYI)

On Thu, Jun 21, 2018 at 5:10 PM kernel test robot wrote: > > FYI, we noticed a -5.6% regression of netperf.Throughput_total_tps due to > commit 050e9b ("Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variables") That's perhaps a surprisingly large cost to stack protecto

Re: [lkp-robot] [Kbuild] 050e9baa9d: netperf.Throughput_total_tps -5.6% regression (FYI)

On Thu, Jun 21, 2018 at 5:10 PM kernel test robot wrote: > > FYI, we noticed a -5.6% regression of netperf.Throughput_total_tps due to > commit 050e9b ("Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variables") That's perhaps a surprisingly large cost to stack protecto

Re: [FYI] GCC segfaults under heavy multithreaded compilation with AMD Ryzen

2017-08-11 19:07 GMT+09:00 Borislav Petkov : > On Wed, Jul 26, 2017 at 06:54:01AM +0900, Satoru Takeuchi wrote: >> # I'm a LKML subscriber, but not a x86 list subscriber >> >> I found the following new linux kernel bugzilla about Ryzen related problem. >> Since many developers

Re: [FYI] GCC segfaults under heavy multithreaded compilation with AMD Ryzen

2017-08-11 19:07 GMT+09:00 Borislav Petkov : > On Wed, Jul 26, 2017 at 06:54:01AM +0900, Satoru Takeuchi wrote: >> # I'm a LKML subscriber, but not a x86 list subscriber >> >> I found the following new linux kernel bugzilla about Ryzen related problem. >> Since many developers don't check this

[FYI] gcc 4.5.1 causes the Linux kernel to hang

[ This is FYI only. Documenting what I found with gcc 4.5.1 (but is fixed in 4.5.4 ] Part of my test suit is to build the kernel with a compiler before asm goto was supported (to test jump labels without it). Recently I noticed that the kernel started to hang when building

[FYI] gcc 4.5.1 causes the Linux kernel to hang

[ This is FYI only. Documenting what I found with gcc 4.5.1 (but is fixed in 4.5.4 ] Part of my test suit is to build the kernel with a compiler before asm goto was supported (to test jump labels without it). Recently I noticed that the kernel started to hang when building

Re: [FYI] GCC segfaults under heavy multithreaded compilation with AMD Ryzen

On Wed, Jul 26, 2017 at 06:54:01AM +0900, Satoru Takeuchi wrote: > # I'm a LKML subscriber, but not a x86 list subscriber > > I found the following new linux kernel bugzilla about Ryzen related problem. > Since many developers don't check this bugzilla and I've also > encountered this problem, >

Re: [FYI] GCC segfaults under heavy multithreaded compilation with AMD Ryzen

On Wed, Jul 26, 2017 at 06:54:01AM +0900, Satoru Takeuchi wrote: > # I'm a LKML subscriber, but not a x86 list subscriber > > I found the following new linux kernel bugzilla about Ryzen related problem. > Since many developers don't check this bugzilla and I've also > encountered this problem, >

Re: Udpated sys_membarrier() speedup patch, FYI

On Mon, Jul 31, 2017 at 11:00:19AM -0700, Dave Watson wrote: > Hi Paul, > > Thanks for looking at this again! > > On 07/27/17 11:12 AM, Paul E. McKenney wrote: > > Hello! > > > > But my main question is whether the throttling shown below is acceptable > > for your use cases, namely only one

Re: Udpated sys_membarrier() speedup patch, FYI

On Mon, Jul 31, 2017 at 11:00:19AM -0700, Dave Watson wrote: > Hi Paul, > > Thanks for looking at this again! > > On 07/27/17 11:12 AM, Paul E. McKenney wrote: > > Hello! > > > > But my main question is whether the throttling shown below is acceptable > > for your use cases, namely only one

Re: [FYI] GCC segfaults under heavy multithreaded compilation with AMD Ryzen

On 07/31/2017 at 02:10 PM Alan Cox wrote: > On Wed, 26 Jul 2017 06:54:01 +0900 > Satoru Takeuchi wrote: > >> # I'm a LKML subscriber, but not a x86 list subscriber >> >> I found the following new linux kernel bugzilla about Ryzen related problem. >> Since many

Re: [FYI] GCC segfaults under heavy multithreaded compilation with AMD Ryzen

On 07/31/2017 at 02:10 PM Alan Cox wrote: > On Wed, 26 Jul 2017 06:54:01 +0900 > Satoru Takeuchi wrote: > >> # I'm a LKML subscriber, but not a x86 list subscriber >> >> I found the following new linux kernel bugzilla about Ryzen related problem. >> Since many developers don't check this

Re: Udpated sys_membarrier() speedup patch, FYI

Hi Paul, Thanks for looking at this again! On 07/27/17 11:12 AM, Paul E. McKenney wrote: > Hello! > > But my main question is whether the throttling shown below is acceptable > for your use cases, namely only one expedited sys_membarrier() permitted > per scheduling-clock period (1 millisecond

Re: Udpated sys_membarrier() speedup patch, FYI

Hi Paul, Thanks for looking at this again! On 07/27/17 11:12 AM, Paul E. McKenney wrote: > Hello! > > But my main question is whether the throttling shown below is acceptable > for your use cases, namely only one expedited sys_membarrier() permitted > per scheduling-clock period (1 millisecond

Re: [FYI] GCC segfaults under heavy multithreaded compilation with AMD Ryzen

On 2017.07.31 at 13:04 +0100, Alan Cox wrote: > On Wed, 26 Jul 2017 06:54:01 +0900 > Satoru Takeuchi wrote: > > > # I'm a LKML subscriber, but not a x86 list subscriber > > > > I found the following new linux kernel bugzilla about Ryzen related problem. > > Since many

Re: [FYI] GCC segfaults under heavy multithreaded compilation with AMD Ryzen

On 2017.07.31 at 13:04 +0100, Alan Cox wrote: > On Wed, 26 Jul 2017 06:54:01 +0900 > Satoru Takeuchi wrote: > > > # I'm a LKML subscriber, but not a x86 list subscriber > > > > I found the following new linux kernel bugzilla about Ryzen related problem. > > Since many developers don't check

Re: [FYI] GCC segfaults under heavy multithreaded compilation with AMD Ryzen

On Wed, 26 Jul 2017 06:54:01 +0900 Satoru Takeuchi wrote: > # I'm a LKML subscriber, but not a x86 list subscriber > > I found the following new linux kernel bugzilla about Ryzen related problem. > Since many developers don't check this bugzilla and I've also >

Re: [FYI] GCC segfaults under heavy multithreaded compilation with AMD Ryzen

On Wed, 26 Jul 2017 06:54:01 +0900 Satoru Takeuchi wrote: > # I'm a LKML subscriber, but not a x86 list subscriber > > I found the following new linux kernel bugzilla about Ryzen related problem. > Since many developers don't check this bugzilla and I've also > encountered this problem, > I

Re: Udpated sys_membarrier() speedup patch, FYI

On 07/31/2017 11:37 AM, Peter Zijlstra wrote: On Mon, Jul 31, 2017 at 09:03:09AM +0300, Avi Kivity wrote: I remembered that current->mm does not change when switching to a kernel task, but my Kernlish is very rusty, or maybe it has changed. kernel threads do indeed preserve the mm of the old

Re: Udpated sys_membarrier() speedup patch, FYI

On 07/31/2017 11:37 AM, Peter Zijlstra wrote: On Mon, Jul 31, 2017 at 09:03:09AM +0300, Avi Kivity wrote: I remembered that current->mm does not change when switching to a kernel task, but my Kernlish is very rusty, or maybe it has changed. kernel threads do indeed preserve the mm of the old

Re: Udpated sys_membarrier() speedup patch, FYI

On Mon, Jul 31, 2017 at 09:03:09AM +0300, Avi Kivity wrote: > I remembered that current->mm does not change when switching to a kernel > task, but my Kernlish is very rusty, or maybe it has changed. kernel threads do indeed preserve the mm of the old userspace task, but we track that in

Re: Udpated sys_membarrier() speedup patch, FYI

On Mon, Jul 31, 2017 at 09:03:09AM +0300, Avi Kivity wrote: > I remembered that current->mm does not change when switching to a kernel > task, but my Kernlish is very rusty, or maybe it has changed. kernel threads do indeed preserve the mm of the old userspace task, but we track that in

Re: Udpated sys_membarrier() speedup patch, FYI

On 07/28/2017 12:02 AM, Mathieu Desnoyers wrote: - On Jul 27, 2017, at 4:58 PM, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: - On Jul 27, 2017, at 4:37 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: On Thu, Jul 27, 2017 at 11:04:13PM +0300, Avi Kivity wrote:

Re: Udpated sys_membarrier() speedup patch, FYI

On 07/28/2017 12:02 AM, Mathieu Desnoyers wrote: - On Jul 27, 2017, at 4:58 PM, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: - On Jul 27, 2017, at 4:37 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: On Thu, Jul 27, 2017 at 11:04:13PM +0300, Avi Kivity wrote:

Re: Udpated sys_membarrier() speedup patch, FYI

On Fri, Jul 28, 2017 at 10:37:25AM -0700, Andrew Hunter wrote: > On Thu, Jul 27, 2017 at 12:06 PM, Paul E. McKenney > wrote: > > IPIin only those CPUs running threads in the same process as the > > thread invoking membarrier() would be very nice! There is some LKML >

Re: Udpated sys_membarrier() speedup patch, FYI

On Fri, Jul 28, 2017 at 10:37:25AM -0700, Andrew Hunter wrote: > On Thu, Jul 27, 2017 at 12:06 PM, Paul E. McKenney > wrote: > > IPIin only those CPUs running threads in the same process as the > > thread invoking membarrier() would be very nice! There is some LKML > > discussion on this topic,

Re: Udpated sys_membarrier() speedup patch, FYI

- On Jul 28, 2017, at 1:31 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: > On Fri, Jul 28, 2017 at 10:15:49AM -0700, Andrew Hunter wrote: >> On Thu, Jul 27, 2017 at 12:43 PM, Paul E. McKenney >> wrote: >> > On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi

Re: Udpated sys_membarrier() speedup patch, FYI

- On Jul 28, 2017, at 1:31 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: > On Fri, Jul 28, 2017 at 10:15:49AM -0700, Andrew Hunter wrote: >> On Thu, Jul 27, 2017 at 12:43 PM, Paul E. McKenney >> wrote: >> > On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi Kivity wrote: >> >> IPIing

Re: Udpated sys_membarrier() speedup patch, FYI

On Thu, Jul 27, 2017 at 12:06 PM, Paul E. McKenney wrote: > IPIin only those CPUs running threads in the same process as the > thread invoking membarrier() would be very nice! There is some LKML > discussion on this topic, which is currently circling around making

Re: Udpated sys_membarrier() speedup patch, FYI

On Thu, Jul 27, 2017 at 12:06 PM, Paul E. McKenney wrote: > IPIin only those CPUs running threads in the same process as the > thread invoking membarrier() would be very nice! There is some LKML > discussion on this topic, which is currently circling around making this > determination reliable

Re: Udpated sys_membarrier() speedup patch, FYI

On Fri, Jul 28, 2017 at 10:15:49AM -0700, Andrew Hunter wrote: > On Thu, Jul 27, 2017 at 12:43 PM, Paul E. McKenney > wrote: > > On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi Kivity wrote: > >> IPIing only running threads of my process would be perfect. In fact > >> I

Re: Udpated sys_membarrier() speedup patch, FYI

On Fri, Jul 28, 2017 at 10:15:49AM -0700, Andrew Hunter wrote: > On Thu, Jul 27, 2017 at 12:43 PM, Paul E. McKenney > wrote: > > On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi Kivity wrote: > >> IPIing only running threads of my process would be perfect. In fact > >> I might even be able to make

Re: Udpated sys_membarrier() speedup patch, FYI

- On Jul 28, 2017, at 1:15 PM, Andrew Hunter a...@google.com wrote: > On Thu, Jul 27, 2017 at 12:43 PM, Paul E. McKenney > wrote: >> On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi Kivity wrote: >>> IPIing only running threads of my process would be perfect. In fact

Re: Udpated sys_membarrier() speedup patch, FYI

- On Jul 28, 2017, at 1:15 PM, Andrew Hunter a...@google.com wrote: > On Thu, Jul 27, 2017 at 12:43 PM, Paul E. McKenney > wrote: >> On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi Kivity wrote: >>> IPIing only running threads of my process would be perfect. In fact >>> I might even be able to

Re: Udpated sys_membarrier() speedup patch, FYI

On Thu, Jul 27, 2017 at 12:43 PM, Paul E. McKenney wrote: > On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi Kivity wrote: >> IPIing only running threads of my process would be perfect. In fact >> I might even be able to make use of "membarrier these threads >> please" to

Re: Udpated sys_membarrier() speedup patch, FYI

On Thu, Jul 27, 2017 at 12:43 PM, Paul E. McKenney wrote: > On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi Kivity wrote: >> IPIing only running threads of my process would be perfect. In fact >> I might even be able to make use of "membarrier these threads >> please" to reduce IPIs, when I change

Re: Udpated sys_membarrier() speedup patch, FYI

- On Jul 27, 2017, at 4:58 PM, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: > - On Jul 27, 2017, at 4:37 PM, Paul E. McKenney paul...@linux.vnet.ibm.com > wrote: > >> On Thu, Jul 27, 2017 at 11:04:13PM +0300, Avi Kivity wrote: [...] >>> >+ >>> >+ this_cpu =

Re: Udpated sys_membarrier() speedup patch, FYI

- On Jul 27, 2017, at 4:58 PM, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: > - On Jul 27, 2017, at 4:37 PM, Paul E. McKenney paul...@linux.vnet.ibm.com > wrote: > >> On Thu, Jul 27, 2017 at 11:04:13PM +0300, Avi Kivity wrote: [...] >>> >+ >>> >+ this_cpu =

Re: Udpated sys_membarrier() speedup patch, FYI

- On Jul 27, 2017, at 4:37 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: > On Thu, Jul 27, 2017 at 11:04:13PM +0300, Avi Kivity wrote: >> On 07/27/2017 10:43 PM, Paul E. McKenney wrote: >> >On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi Kivity wrote: >> >>On 07/27/2017 09:12 PM, Paul

Re: Udpated sys_membarrier() speedup patch, FYI

- On Jul 27, 2017, at 4:37 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: > On Thu, Jul 27, 2017 at 11:04:13PM +0300, Avi Kivity wrote: >> On 07/27/2017 10:43 PM, Paul E. McKenney wrote: >> >On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi Kivity wrote: >> >>On 07/27/2017 09:12 PM, Paul

Re: Udpated sys_membarrier() speedup patch, FYI

On Thu, Jul 27, 2017 at 11:04:13PM +0300, Avi Kivity wrote: > On 07/27/2017 10:43 PM, Paul E. McKenney wrote: > >On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi Kivity wrote: > >>On 07/27/2017 09:12 PM, Paul E. McKenney wrote: > >>>Hello! > >>> > >>>Please see below for a prototype sys_membarrier()

  1   2   3   4   5   >