From: "Alex Xu (Hello71)" <alex_y_xu@yahoo.ca> To: paulmck@kernel.org, rcu@vger.kernel.org, urezki@gmail.com, uladzislau.rezki@sony.com, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "Arve Hjønnevåg" <arve@android.com>, "Todd Kjos" <tkjos@android.com>, "Martijn Coenen" <maco@android.com>, "Joel Fernandes" <joel@joelfernandes.org>, "Christian Brauner" <christian@brauner.io>, "Hridya Valsaraju" <hridya@google.com>, "Suren Baghdasaryan" <surenb@google.com>, linux-kernel@vger.kernel.org, "Jason A. Donenfeld" <Jason@zx2c4.com>, wireguard@lists.zx2c4.com, "Theodore Ts'o" <tytso@mit.edu> Cc: alexander.deucher@amd.com, christian.koenig@amd.com, Xinhui.Pan@amd.com, amd-gfx@lists.freedesktop.org Subject: CONFIG_ANDROID (was: rcu_sched detected expedited stalls in amdgpu after suspend) Date: Tue, 28 Jun 2022 11:02:40 -0400 [thread overview] Message-ID: <1656421946.ic03168yc3.none@localhost> (raw) In-Reply-To: <20220628041252.GV1790663@paulmck-ThinkPad-P17-Gen-1> Excerpts from Paul E. McKenney's message of June 28, 2022 12:12 am: > On Mon, Jun 27, 2022 at 09:50:53PM -0400, Alex Xu (Hello71) wrote: >> Ah, I see. I have selected the default value for >> CONFIG_RCU_EXP_CPU_STALL_TIMEOUT, but that is 20 if ANDROID. I am not >> using Android; I'm not sure there exist Android devices with AMD GPUs. >> However, I have set CONFIG_ANDROID=y in order to use >> ANDROID_BINDER_IPC=m for emulation. >> >> In general, I think CONFIG_ANDROID is not a reliable method for >> detecting if the kernel is for an Android device; for example, Fedora >> sets CONFIG_ANDROID, but (AFAIK) its kernel is not intended for use with >> Android userspace. >> >> On the other hand, it's not clear to me why the value 20 should be for >> Android only anyways. If, as you say in >> https://lore.kernel.org/lkml/20220216195508.GM4285@paulmck-ThinkPad-P17-Gen-1/, >> it is related to the size of the system, perhaps some other heuristic >> would be more appropriate. > > It is related to the fact that quite a few Android guys want these > 20-millisecond short-timeout expedited RCU CPU stall warnings, but no one > else does. Not yet anyway. > > And let's face it, the intent and purpose of CONFIG_ANDROID=y is extremely > straightforward and unmistakeable. So perhaps people not running Android > devices but wanting a little bit of the Android functionality should do > something other than setting CONFIG_ANDROID=y in their .config files. Me, > I am surprised that it took this long for something like this to bite you. > > But just out of curiosity, what would you suggest instead? Both Debian and Fedora set CONFIG_ANDROID, specifically for binder. If major distro vendors are consistently making this "mistake", then perhaps the problem is elsewhere. In my own opinion, assuming that binderfs means Android vendor is not a good assumption. The ANDROID help says: > Enable support for various drivers needed on the Android platform It doesn't say "Enable only if building an Android device", or "Enable only if you are Google". Isn't the traditional Linux philosophy a collection of pieces to be assembled, without gratuitous hidden dependencies? For example, [0] removes the unnecessary Android dependency, it doesn't block the whole thing with "depends on ANDROID". It seems to me that the proper way to set some configuration for Android kernels is or should be to ask the Android kernel config maintainers, not to set it based on an upstream kernel option. There is, after all, no CONFIG_FEDORA or CONFIG_UBUNTU or CONFIG_HANNAH_MONTANA. WireGuard and random also use CONFIG_ANDROID in a similar "proxy" way as rcu, there to see if suspends are "frequent". This seems dubious for the same reasons. I wonder if it might be time to retire CONFIG_ANDROID: the only remaining driver covered is binder, which originates from Android but is no longer used exclusively on Android systems. Like ufs-qcom, binder is no longer used exclusively on Android devices; it is also used for Android device emulators, which might be used on Android-like mobile devices, or might not. My understanding is that both Android and upstream kernel developers intend to add no more Android-specific drivers, so binder should be the only one covered for the foreseeable future. > For that matter, why the private reply? Mail client issues, not intentional. Lists re-added, plus Android, WireGuard, and random. Thanks, Alex. [0] https://lore.kernel.org/all/20220321151853.24138-1-krzk@kernel.org/
WARNING: multiple messages have this Message-ID (diff)
From: "Alex Xu (Hello71)" <alex_y_xu@yahoo.ca> To: paulmck@kernel.org, rcu@vger.kernel.org, urezki@gmail.com, uladzislau.rezki@sony.com, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "Arve Hjønnevåg" <arve@android.com>, "Todd Kjos" <tkjos@android.com>, "Martijn Coenen" <maco@android.com>, "Joel Fernandes" <joel@joelfernandes.org>, "Christian Brauner" <christian@brauner.io>, "Hridya Valsaraju" <hridya@google.com>, "Suren Baghdasaryan" <surenb@google.com>, linux-kernel@vger.kernel.org, "Jason A. Donenfeld" <Jason@zx2c4.com>, wireguard@lists.zx2c4.com, "Theodore Ts'o" <tytso@mit.edu> Cc: alexander.deucher@amd.com, Xinhui.Pan@amd.com, christian.koenig@amd.com, amd-gfx@lists.freedesktop.org Subject: CONFIG_ANDROID (was: rcu_sched detected expedited stalls in amdgpu after suspend) Date: Tue, 28 Jun 2022 11:02:40 -0400 [thread overview] Message-ID: <1656421946.ic03168yc3.none@localhost> (raw) In-Reply-To: <20220628041252.GV1790663@paulmck-ThinkPad-P17-Gen-1> Excerpts from Paul E. McKenney's message of June 28, 2022 12:12 am: > On Mon, Jun 27, 2022 at 09:50:53PM -0400, Alex Xu (Hello71) wrote: >> Ah, I see. I have selected the default value for >> CONFIG_RCU_EXP_CPU_STALL_TIMEOUT, but that is 20 if ANDROID. I am not >> using Android; I'm not sure there exist Android devices with AMD GPUs. >> However, I have set CONFIG_ANDROID=y in order to use >> ANDROID_BINDER_IPC=m for emulation. >> >> In general, I think CONFIG_ANDROID is not a reliable method for >> detecting if the kernel is for an Android device; for example, Fedora >> sets CONFIG_ANDROID, but (AFAIK) its kernel is not intended for use with >> Android userspace. >> >> On the other hand, it's not clear to me why the value 20 should be for >> Android only anyways. If, as you say in >> https://lore.kernel.org/lkml/20220216195508.GM4285@paulmck-ThinkPad-P17-Gen-1/, >> it is related to the size of the system, perhaps some other heuristic >> would be more appropriate. > > It is related to the fact that quite a few Android guys want these > 20-millisecond short-timeout expedited RCU CPU stall warnings, but no one > else does. Not yet anyway. > > And let's face it, the intent and purpose of CONFIG_ANDROID=y is extremely > straightforward and unmistakeable. So perhaps people not running Android > devices but wanting a little bit of the Android functionality should do > something other than setting CONFIG_ANDROID=y in their .config files. Me, > I am surprised that it took this long for something like this to bite you. > > But just out of curiosity, what would you suggest instead? Both Debian and Fedora set CONFIG_ANDROID, specifically for binder. If major distro vendors are consistently making this "mistake", then perhaps the problem is elsewhere. In my own opinion, assuming that binderfs means Android vendor is not a good assumption. The ANDROID help says: > Enable support for various drivers needed on the Android platform It doesn't say "Enable only if building an Android device", or "Enable only if you are Google". Isn't the traditional Linux philosophy a collection of pieces to be assembled, without gratuitous hidden dependencies? For example, [0] removes the unnecessary Android dependency, it doesn't block the whole thing with "depends on ANDROID". It seems to me that the proper way to set some configuration for Android kernels is or should be to ask the Android kernel config maintainers, not to set it based on an upstream kernel option. There is, after all, no CONFIG_FEDORA or CONFIG_UBUNTU or CONFIG_HANNAH_MONTANA. WireGuard and random also use CONFIG_ANDROID in a similar "proxy" way as rcu, there to see if suspends are "frequent". This seems dubious for the same reasons. I wonder if it might be time to retire CONFIG_ANDROID: the only remaining driver covered is binder, which originates from Android but is no longer used exclusively on Android systems. Like ufs-qcom, binder is no longer used exclusively on Android devices; it is also used for Android device emulators, which might be used on Android-like mobile devices, or might not. My understanding is that both Android and upstream kernel developers intend to add no more Android-specific drivers, so binder should be the only one covered for the foreseeable future. > For that matter, why the private reply? Mail client issues, not intentional. Lists re-added, plus Android, WireGuard, and random. Thanks, Alex. [0] https://lore.kernel.org/all/20220321151853.24138-1-krzk@kernel.org/
next prev parent reply other threads:[~2022-06-28 15:03 UTC|newest] Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <1656357116.rhe0mufk6a.none.ref@localhost> 2022-06-27 19:22 ` rcu_sched detected expedited stalls in amdgpu after suspend Alex Xu (Hello71) 2022-06-27 20:41 ` Paul E. McKenney 2022-06-27 20:41 ` Paul E. McKenney [not found] ` <1656379893.q9yb069erk.none@localhost> [not found] ` <20220628041252.GV1790663@paulmck-ThinkPad-P17-Gen-1> 2022-06-28 15:02 ` Alex Xu (Hello71) [this message] 2022-06-28 15:02 ` CONFIG_ANDROID (was: rcu_sched detected expedited stalls in amdgpu after suspend) Alex Xu (Hello71) 2022-06-28 15:13 ` Jason A. Donenfeld 2022-06-28 15:13 ` Jason A. Donenfeld 2022-06-28 18:54 ` Paul E. McKenney 2022-06-28 18:54 ` Paul E. McKenney 2022-06-28 19:28 ` Alex Xu (Hello71) 2022-06-28 19:28 ` Alex Xu (Hello71) 2022-06-28 20:11 ` Uladzislau Rezki 2022-06-28 20:11 ` Uladzislau Rezki 2022-07-04 11:30 ` Christian König 2022-07-04 11:30 ` Christian König 2022-07-06 17:48 ` Uladzislau Rezki 2022-07-06 17:48 ` Uladzislau Rezki 2022-07-06 17:58 ` Paul E. McKenney 2022-07-06 17:58 ` Paul E. McKenney 2022-07-06 18:09 ` Uladzislau Rezki 2022-07-06 18:09 ` Uladzislau Rezki 2022-07-06 20:42 ` Paul E. McKenney 2022-07-06 20:42 ` Paul E. McKenney 2022-07-07 7:30 ` Christian König 2022-07-07 7:30 ` Christian König 2022-07-07 13:29 ` Paul E. McKenney 2022-07-07 13:29 ` Paul E. McKenney
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=1656421946.ic03168yc3.none@localhost \ --to=alex_y_xu@yahoo.ca \ --cc=Jason@zx2c4.com \ --cc=Xinhui.Pan@amd.com \ --cc=alexander.deucher@amd.com \ --cc=amd-gfx@lists.freedesktop.org \ --cc=arve@android.com \ --cc=christian.koenig@amd.com \ --cc=christian@brauner.io \ --cc=gregkh@linuxfoundation.org \ --cc=hridya@google.com \ --cc=joel@joelfernandes.org \ --cc=linux-kernel@vger.kernel.org \ --cc=maco@android.com \ --cc=paulmck@kernel.org \ --cc=rcu@vger.kernel.org \ --cc=surenb@google.com \ --cc=tkjos@android.com \ --cc=tytso@mit.edu \ --cc=uladzislau.rezki@sony.com \ --cc=urezki@gmail.com \ --cc=wireguard@lists.zx2c4.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.