Re: [RFC 2/5] i3c: Add core I3C infrastructure
On Tue, 1 Aug 2017 17:20:41 +0200 Boris Brezillon wrote: > On Tue, 1 Aug 2017 17:01:08 +0200 > Wolfram Sang wrote: > > > > I do not know of any real devices as of today (all my tests have been > > > done with a dummy/fake I3C slaves emulated with a slave IP), > > > > I see. > > > > > spec clearly describe what legacy/static addresses are for and one of > > > their use case is to connect an I3C device on an I2C bus and let it act > > > as an I2C device. > > > > OK. That makes it more likely. > > > > > Unless you want your device (likely a sensor) to be compatible with both > > > I3C and I2C so that you can target even more people. > > > > Right. My question was if this is a realistic or more academic scenario. > > > > > I'm perfectly fine with the I3C / I2C framework separation. The only > > > minor problem I had with that was the inaccuracy of the > > > sysfs/device-model representation: we don't have one i2c and one i3c > > > bus, we just have one i3c bus with a mix of i2c and i3c devices. > > > > I understand that. What if I2C had the same seperation between the "bus" > > and the "master"? > > > > Yep, it might work if we can register an i2c_adapter and pass it an > existing bus object. We'd still need a common base for i2c and i3c > busses, unless we consider the bus as an opaque "struct device *" > object. I tried to envision how this could be implemented but realized separating the bus and master concepts in I2C wouldn't solve all problems. Each device is attached a bus_type which defines how to match devices and drivers, uevent format, ... But it also defines where the device appears in sysfs (/sys/bus//devices). First question: where should an I2C device connected on an I3C bus appear? /sys/bus/i3c/devices/ or /sys/bus/i2c/devices/? I'd say both (with one of them being a symlink to the other) but I'm not sure. Also, if we go for a 'single bus per master' representation but still want i3c and i2c to be differentiated, that means when one adds an i2c_driver we'll have to duplicate this driver object and register one instance to the i2c framework and the other one to the i3c framework, because device <-> driver matching is done per bus_type. One solution would be to go for Arnd suggestion to extend i2c_bus_type with I3C support, but then i3c related kojects would be exposed under /sys/bus/i2c/ which can be disturbing for people who are used to look at /sys/bus/ to find devices connected on a specific bus type. Honestly, I don't know what's the best solution here. Every solution has its pros and cons: 1/ The "one i2c bus and one i3c bus per i3c master" I proposed in this RFC is non-invasive but the resulting sysfs/device-model representation is not accurate. 2/ Separating the I3C and I2C framework with a thin layer between them to propagate i2c drivers registration to the i3c framework and make sure i2c devices are exposed in both worlds is much more complicated to implement but should provide an accurate bus <-> device representation. 3/ Extending i2c_bus_type (and more generally the I2C framework) to support I3C devices/busses is invasive and we still have a non-accurate representation (i2c busses are mixed with i3c busses and all exposed under /sys/bus/i2c/). One advantage with this solution compared to #2 is that we don't need to duplicate i2c_driver objects in order to register them to both i2c and i3c bus types. Any advice is welcome. Thanks, Boris -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v4 2/4] mm, oom: cgroup-aware OOM killer
On Wed, Aug 02, 2017 at 09:29:01AM +0200, Michal Hocko wrote: > On Tue 01-08-17 19:13:52, Roman Gushchin wrote: > > On Tue, Aug 01, 2017 at 07:03:03PM +0200, Michal Hocko wrote: > > > On Tue 01-08-17 16:25:48, Roman Gushchin wrote: > > > > On Tue, Aug 01, 2017 at 04:54:35PM +0200, Michal Hocko wrote: > > > [...] > > > > > I would reap out the oom_kill_process into a separate patch. > > > > > > > > It was a separate patch, I've merged it based on Vladimir's feedback. > > > > No problems, I can divide it back. > > > > > > It would make the review slightly more easier > > > > > > > > > > -static void oom_kill_process(struct oom_control *oc, const char > > > > > > *message) > > > > > > +static void __oom_kill_process(struct task_struct *victim) > > > > > > > > > > To the rest of the patch. I have to say I do not quite like how it is > > > > > implemented. I was hoping for something much simpler which would hook > > > > > into oom_evaluate_task. If a task belongs to a memcg with kill-all > > > > > flag > > > > > then we would update the cumulative memcg badness (more specifically > > > > > the > > > > > badness of the topmost parent with kill-all flag). Memcg will then > > > > > compete with existing self contained tasks (oom_badness will have to > > > > > tell whether points belong to a task or a memcg to allow the caller to > > > > > deal with it). But it shouldn't be much more complex than that. > > > > > > > > I'm not sure, it will be any simpler. Basically I'm doing the same: > > > > the difference is that you want to iterate over tasks and for each > > > > task traverse the memcg tree, update per-cgroup oom score and find > > > > the corresponding memcg(s) with the kill-all flag. I'm doing the > > > > opposite: > > > > traverse the cgroup tree, and for each leaf cgroup iterate over > > > > processes. > > > > > > Yeah but this doesn't fit very well to the existing scheme so we would > > > need two different schemes which is not ideal from maint. point of view. > > > We also do not have to duplicate all the tricky checks we already do in > > > oom_evaluate_task. So I would prefer if we could try to hook there and > > > do the special handling there. > > > > I hope, that iterating over all tasks just to check if there are > > in-flight OOM victims might be optimized at some point. > > That means, we would be able to choose a victim much cheaper. > > It's not easy, but it feels as a right direction to go. > > You would have to count per each oom domain and that sounds quite > unfeasible to me. It's hard, but traversing the whole cgroup tree from bottom to top for each task is just not scalable. This is exactly why I've choosen a compromise right now: let's iterate over all tasks, but do it by iterating over the cgroup tree. > > > Also, adding new tricks to the oom_evaluate_task() will make the code > > even more hairy. Some of the existing tricks are useless for memcg > > selection. > > Not sure what you mean but oom_evaluate_task has been usable for both > global and memcg oom paths so far. I do not see any reason why this > shouldn't hold for a different oom killing strategy. Yes, but in both cases we've evaluated tasks, not cgroups. > > > > > Also, please note, that even without the kill-all flag the decision is > > > > made > > > > on per-cgroup level (except tasks in the root cgroup). > > > > > > Yeah and I am not sure this is a reasonable behavior. Why should we > > > consider memcgs which are not kill-all as a single entity? > > > > I think, it's reasonable to choose a cgroup/container to blow off based on > > the cgroup oom_priority/size (including hierarchical settings), and then > > kill one biggest or all tasks depending on cgroup settings. > > But that doesn't mean you have to treat even !kill-all memcgs like a > single entity. In fact we should compare killable entities which is > either a task or the whole memcg if configured that way. I believe it's absolutely valid user's intention to prioritize some cgroups over other, even if only one task should be killed in case of OOM. Thanks! Roman -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v4 2/4] mm, oom: cgroup-aware OOM killer
On Thu 03-08-17 13:47:51, Roman Gushchin wrote: > On Wed, Aug 02, 2017 at 09:29:01AM +0200, Michal Hocko wrote: > > On Tue 01-08-17 19:13:52, Roman Gushchin wrote: > > > On Tue, Aug 01, 2017 at 07:03:03PM +0200, Michal Hocko wrote: > > > > On Tue 01-08-17 16:25:48, Roman Gushchin wrote: > > > > > On Tue, Aug 01, 2017 at 04:54:35PM +0200, Michal Hocko wrote: > > > > [...] > > > > > > I would reap out the oom_kill_process into a separate patch. > > > > > > > > > > It was a separate patch, I've merged it based on Vladimir's feedback. > > > > > No problems, I can divide it back. > > > > > > > > It would make the review slightly more easier > > > > > > > > > > > > -static void oom_kill_process(struct oom_control *oc, const char > > > > > > > *message) > > > > > > > +static void __oom_kill_process(struct task_struct *victim) > > > > > > > > > > > > To the rest of the patch. I have to say I do not quite like how it > > > > > > is > > > > > > implemented. I was hoping for something much simpler which would > > > > > > hook > > > > > > into oom_evaluate_task. If a task belongs to a memcg with kill-all > > > > > > flag > > > > > > then we would update the cumulative memcg badness (more > > > > > > specifically the > > > > > > badness of the topmost parent with kill-all flag). Memcg will then > > > > > > compete with existing self contained tasks (oom_badness will have to > > > > > > tell whether points belong to a task or a memcg to allow the caller > > > > > > to > > > > > > deal with it). But it shouldn't be much more complex than that. > > > > > > > > > > I'm not sure, it will be any simpler. Basically I'm doing the same: > > > > > the difference is that you want to iterate over tasks and for each > > > > > task traverse the memcg tree, update per-cgroup oom score and find > > > > > the corresponding memcg(s) with the kill-all flag. I'm doing the > > > > > opposite: > > > > > traverse the cgroup tree, and for each leaf cgroup iterate over > > > > > processes. > > > > > > > > Yeah but this doesn't fit very well to the existing scheme so we would > > > > need two different schemes which is not ideal from maint. point of view. > > > > We also do not have to duplicate all the tricky checks we already do in > > > > oom_evaluate_task. So I would prefer if we could try to hook there and > > > > do the special handling there. > > > > > > I hope, that iterating over all tasks just to check if there are > > > in-flight OOM victims might be optimized at some point. > > > That means, we would be able to choose a victim much cheaper. > > > It's not easy, but it feels as a right direction to go. > > > > You would have to count per each oom domain and that sounds quite > > unfeasible to me. > > It's hard, but traversing the whole cgroup tree from bottom to top > for each task is just not scalable. We are talking about the oom path which is a slow path. Besides that memcg hierarchies will not be very deep usually (we are not talking about hundreds). > This is exactly why I've choosen a compromise right now: let's > iterate over all tasks, but do it by iterating over the cgroup tree. > > > > > > Also, adding new tricks to the oom_evaluate_task() will make the code > > > even more hairy. Some of the existing tricks are useless for memcg > > > selection. > > > > Not sure what you mean but oom_evaluate_task has been usable for both > > global and memcg oom paths so far. I do not see any reason why this > > shouldn't hold for a different oom killing strategy. > > Yes, but in both cases we've evaluated tasks, not cgroups. > > > > > > > > Also, please note, that even without the kill-all flag the decision > > > > > is made > > > > > on per-cgroup level (except tasks in the root cgroup). > > > > > > > > Yeah and I am not sure this is a reasonable behavior. Why should we > > > > consider memcgs which are not kill-all as a single entity? > > > > > > I think, it's reasonable to choose a cgroup/container to blow off based on > > > the cgroup oom_priority/size (including hierarchical settings), and then > > > kill one biggest or all tasks depending on cgroup settings. > > > > But that doesn't mean you have to treat even !kill-all memcgs like a > > single entity. In fact we should compare killable entities which is > > either a task or the whole memcg if configured that way. > > I believe it's absolutely valid user's intention to prioritize some > cgroups over other, even if only one task should be killed in case of OOM. This is mixing different concepts which I really dislike. The semantic is getting really fuzzy. How are you going to apply memcg priority when you are killing a single task? What portion of the memcgs priority does the task get? Then you have that root is special... No I really dislike this. We should start simple and compare killable entities. If you want to apply memcg priority then only on the whole memcgs. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubs
Re: [PATCH 01/11] arm64: docs: describe ELF hwcaps
On Wed, Jul 19, 2017 at 9:01 AM, Mark Rutland wrote: > We don't document our ELF hwcaps, leaving developers to interpret them > according to hearsay, guesswork, or (in exceptional cases) inspection of > the current kernel code. > > This is less than optimal, and it would be far better if we had some > definitive description of each of the ELF hwcaps that developers could > refer to. > > This patch adds a document describing the (native) arm64 ELF hwcaps. > > Signed-off-by: Mark Rutland > Cc: Catalin Marinas > Cc: Dave Martin > Cc: Suzuki K Poulose > Cc: Will Deacon > --- > Documentation/arm64/elf_hwcaps.txt | 133 > + With the kernel docs moving to ReST markup[1], perhaps reformat this to a .rst file and link to it from somewhere sensible in the ReST tree, perhaps the userspace API section in Documentation/userspace-api/index.rst? -Kees [1] https://www.kernel.org/doc/html/latest/doc-guide/sphinx.html -- Kees Cook Pixel Security -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 10/10] dt-bindings: i2c: Add P8 OCC hwmon driver documentation
On Thu, Jul 27, 2017 at 09:30:29AM -0500, Eddie James wrote:
> From: "Edward A. James"
>
> Document the bindings for I2C-based OCC hwmon driver.
>
> Signed-off-by: Edward A. James
> ---
> .../devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt | 25
> ++
> 1 file changed, 25 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt
>
> diff --git a/Documentation/devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt
> b/Documentation/devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt
> new file mode 100644
> index 000..8c765d0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt
> @@ -0,0 +1,25 @@
> +Device-tree bindings for I2C-based On-Chip Controller hwmon driver
> +--
Bindings describe hardware, not Linux subsystems or drivers.
> +
> +Required properties:
> + - compatible = "ibm,p8-occ-hwmon";
> + - reg = ; : I2C bus address
> +
> +Examples:
> +
> +i2c-bus@100 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +clock-frequency = <10>;
> +< more properties >
> +
> +occ-hwmon@1 {
> +compatible = "ibm,p8-occ-hwmon";
> +reg = <0x50>;
> +};
> +
> +occ-hwmon@2 {
> +compatible = "ibm,p8-occ-hwmon";
> +reg = <0x51>;
> +};
> +};
> --
> 1.8.3.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] printk: Add boottime and real timestamps
printk.time=1/CONFIG_PRINTK_TIME=1 adds a unmodified local hardware clock timestamp to printk messages. The local hardware clock loses time each day making it difficult to determine exactly when an issue has occurred in the kernel log, and making it difficult to determine how kernel and hardware issues relate to each other in real time. Make printk output different timestampes by adding options for no timestamp, the local hardware clock, the monotonic clock, and the real clock. Allow a user to pick one of the clocks by using the printk.time kernel parameter. Output the type of clock in /sys/module/printk/parameters/time so userspace programs can interpret the timestamp. Real clock & 32-bit systems: Selecting the real clock printk timestamp may lead to unlikely situations where a timestamp is wrong because the real time offset is read without the protection of a sequence lock in the call to ktime_get_log_ts() in printk_get_ts(). v2: Use peterz's suggested Kconfig options. Merge patchset together. Fix i386 !CONFIG_PRINTK builds. v3: Fixed x86_64_defconfig. Added & kdoc'ifyied printk_time_type enum and printk_time_str for better output. Added BOOTTIME clock functionality. Signed-off-by: Prarit Bhargava Cc: Mark Salyzyn Cc: Jonathan Corbet Cc: Petr Mladek Cc: Sergey Senozhatsky Cc: Steven Rostedt Cc: John Stultz Cc: Thomas Gleixner Cc: Stephen Boyd Cc: Andrew Morton Cc: Greg Kroah-Hartman Cc: "Paul E. McKenney" Cc: Christoffer Dall Cc: Deepa Dinamani Cc: Ingo Molnar Cc: Joel Fernandes Cc: Kees Cook Cc: Peter Zijlstra Cc: Geert Uytterhoeven Cc: "Luis R. Rodriguez" Cc: Nicholas Piggin Cc: "Jason A. Donenfeld" Cc: Olof Johansson Cc: Josh Poimboeuf Cc: linux-doc@vger.kernel.org --- Documentation/admin-guide/kernel-parameters.txt| 6 +- arch/arm/configs/aspeed_g4_defconfig | 4 +- arch/arm/configs/aspeed_g5_defconfig | 4 +- arch/arm/configs/axm55xx_defconfig | 4 +- arch/arm/configs/bcm2835_defconfig | 4 +- arch/arm/configs/colibri_pxa270_defconfig | 4 +- arch/arm/configs/colibri_pxa300_defconfig | 4 +- arch/arm/configs/dove_defconfig| 4 +- arch/arm/configs/efm32_defconfig | 4 +- arch/arm/configs/exynos_defconfig | 4 +- arch/arm/configs/ezx_defconfig | 4 +- arch/arm/configs/h5000_defconfig | 4 +- arch/arm/configs/hisi_defconfig| 4 +- arch/arm/configs/imote2_defconfig | 4 +- arch/arm/configs/imx_v6_v7_defconfig | 4 +- arch/arm/configs/keystone_defconfig| 4 +- arch/arm/configs/lpc18xx_defconfig | 4 +- arch/arm/configs/magician_defconfig| 4 +- arch/arm/configs/mmp2_defconfig| 4 +- arch/arm/configs/moxart_defconfig | 4 +- arch/arm/configs/mps2_defconfig| 4 +- arch/arm/configs/multi_v7_defconfig| 4 +- arch/arm/configs/mvebu_v7_defconfig| 4 +- arch/arm/configs/mxs_defconfig | 4 +- arch/arm/configs/omap2plus_defconfig | 4 +- arch/arm/configs/pxa168_defconfig | 4 +- arch/arm/configs/pxa3xx_defconfig | 4 +- arch/arm/configs/pxa910_defconfig | 4 +- arch/arm/configs/pxa_defconfig | 4 +- arch/arm/configs/qcom_defconfig| 4 +- arch/arm/configs/raumfeld_defconfig| 4 +- arch/arm/configs/shmobile_defconfig| 4 +- arch/arm/configs/socfpga_defconfig | 4 +- arch/arm/configs/stm32_defconfig | 4 +- arch/arm/configs/sunxi_defconfig | 4 +- arch/arm/configs/tango4_defconfig | 4 +- arch/arm/configs/tegra_defconfig | 4 +- arch/arm/configs/u300_defconfig| 4 +- arch/arm/configs/u8500_defconfig | 4 +- arch/arm/configs/vt8500_v6_v7_defconfig| 4 +- arch/arm/configs/xcep_defconfig| 4 +- arch/arm/configs/zx_defconfig | 4 +- arch/arm64/configs/defconfig | 4 +- arch/m68k/configs/amcore_defconfig | 4 +- arch/mips/configs/ath25_defconfig | 4 +- arch/mips/configs/bcm47xx_defconfig| 4 +- arch/mips/configs/bmips_be_defconfig | 4 +- arch/mips/configs/bmips_stb_defconfig | 4 +- arch/mips/configs/ci20_defconfig | 4 +- arch/mips/configs/generic_defconfig| 4 +- arch/mips/configs/lemote2f_defconfig | 4 +- arch/mips/configs/loongson3_defconfig | 4 +- arch/mips/configs/nlm_xlp_defconfig| 4 +- arch/mips/configs/nlm_xlr_de
