All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH tip/core/rcu 8/9] rcu: Add extended-quiescent-state testing advice
From: Paul E. McKenney @ 2017-10-04 21:29 UTC (permalink / raw)
  To: linux-kernel
  Cc: mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh,
	tglx, peterz, rostedt, dhowells, edumazet, fweisbec, oleg,
	Paul E. McKenney
In-Reply-To: <20171004212915.GA10089@linux.vnet.ibm.com>

If you add or remove calls to rcu_idle_enter(), rcu_user_enter(),
rcu_irq_exit(), rcu_irq_exit_irqson(), rcu_idle_exit(), rcu_user_exit(),
rcu_irq_enter(), rcu_irq_enter_irqson(), rcu_nmi_enter(), or
rcu_nmi_exit(), you should run a full set of tests on a kernel built
with CONFIG_RCU_EQS_DEBUG=y.

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
 kernel/rcu/tree.c | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 0c44c7b42e6d..5186fcea8ba3 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -837,6 +837,9 @@ static void rcu_eqs_enter(bool user)
  * We crowbar the ->dynticks_nesting field to zero to allow for
  * the possibility of usermode upcalls having messed up our count
  * of interrupt nesting level during the prior busy period.
+ *
+ * If you add or remove a call to rcu_idle_enter(), be sure to test with
+ * CONFIG_RCU_EQS_DEBUG=y.
  */
 void rcu_idle_enter(void)
 {
@@ -852,6 +855,9 @@ void rcu_idle_enter(void)
  * is permitted between this call and rcu_user_exit(). This way the
  * CPU doesn't need to maintain the tick for RCU maintenance purposes
  * when the CPU runs in userspace.
+ *
+ * If you add or remove a call to rcu_user_enter(), be sure to test with
+ * CONFIG_RCU_EQS_DEBUG=y.
  */
 void rcu_user_enter(void)
 {
@@ -875,6 +881,9 @@ void rcu_user_enter(void)
  * Use things like work queues to work around this limitation.
  *
  * You have been warned.
+ *
+ * If you add or remove a call to rcu_irq_exit(), be sure to test with
+ * CONFIG_RCU_EQS_DEBUG=y.
  */
 void rcu_irq_exit(void)
 {
@@ -899,6 +908,9 @@ void rcu_irq_exit(void)
 
 /*
  * Wrapper for rcu_irq_exit() where interrupts are enabled.
+ *
+ * If you add or remove a call to rcu_irq_exit_irqson(), be sure to test
+ * with CONFIG_RCU_EQS_DEBUG=y.
  */
 void rcu_irq_exit_irqson(void)
 {
@@ -971,6 +983,9 @@ static void rcu_eqs_exit(bool user)
  * allow for the possibility of usermode upcalls messing up our count
  * of interrupt nesting level during the busy period that is just
  * now starting.
+ *
+ * If you add or remove a call to rcu_idle_exit(), be sure to test with
+ * CONFIG_RCU_EQS_DEBUG=y.
  */
 void rcu_idle_exit(void)
 {
@@ -987,6 +1002,9 @@ void rcu_idle_exit(void)
  *
  * Exit RCU idle mode while entering the kernel because it can
  * run a RCU read side critical section anytime.
+ *
+ * If you add or remove a call to rcu_user_exit(), be sure to test with
+ * CONFIG_RCU_EQS_DEBUG=y.
  */
 void rcu_user_exit(void)
 {
@@ -1012,6 +1030,9 @@ void rcu_user_exit(void)
  * Use things like work queues to work around this limitation.
  *
  * You have been warned.
+ *
+ * If you add or remove a call to rcu_irq_enter(), be sure to test with
+ * CONFIG_RCU_EQS_DEBUG=y.
  */
 void rcu_irq_enter(void)
 {
@@ -1037,6 +1058,9 @@ void rcu_irq_enter(void)
 
 /*
  * Wrapper for rcu_irq_enter() where interrupts are enabled.
+ *
+ * If you add or remove a call to rcu_irq_enter_irqson(), be sure to test
+ * with CONFIG_RCU_EQS_DEBUG=y.
  */
 void rcu_irq_enter_irqson(void)
 {
@@ -1055,6 +1079,9 @@ void rcu_irq_enter_irqson(void)
  * that the CPU is active.  This implementation permits nested NMIs, as
  * long as the nesting level does not overflow an int.  (You will probably
  * run out of stack space first.)
+ *
+ * If you add or remove a call to rcu_nmi_enter(), be sure to test
+ * with CONFIG_RCU_EQS_DEBUG=y.
  */
 void rcu_nmi_enter(void)
 {
@@ -1087,6 +1114,9 @@ void rcu_nmi_enter(void)
  * RCU-idle period, update rdtp->dynticks and rdtp->dynticks_nmi_nesting
  * to let the RCU grace-period handling know that the CPU is back to
  * being RCU-idle.
+ *
+ * If you add or remove a call to rcu_nmi_exit(), be sure to test
+ * with CONFIG_RCU_EQS_DEBUG=y.
  */
 void rcu_nmi_exit(void)
 {
-- 
2.5.2

^ permalink raw reply related

* [PATCH tip/core/rcu 6/9] sched: Make resched_cpu() unconditional
From: Paul E. McKenney @ 2017-10-04 21:29 UTC (permalink / raw)
  To: linux-kernel
  Cc: mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh,
	tglx, peterz, rostedt, dhowells, edumazet, fweisbec, oleg,
	Paul E. McKenney, stable
In-Reply-To: <20171004212915.GA10089@linux.vnet.ibm.com>

The current implementation of synchronize_sched_expedited() incorrectly
assumes that resched_cpu() is unconditional, which it is not.  This means
that synchronize_sched_expedited() can hang when resched_cpu()'s trylock
fails as follows (analysis by Neeraj Upadhyay):

o	CPU1 is waiting for expedited wait to complete:

	sync_rcu_exp_select_cpus
	     rdp->exp_dynticks_snap & 0x1   // returns 1 for CPU5
	     IPI sent to CPU5

	synchronize_sched_expedited_wait
		 ret = swait_event_timeout(rsp->expedited_wq,
					   sync_rcu_preempt_exp_done(rnp_root),
					   jiffies_stall);

	expmask = 0x20, CPU 5 in idle path (in cpuidle_enter())

o	CPU5 handles IPI and fails to acquire rq lock.

	Handles IPI
	     sync_sched_exp_handler
		 resched_cpu
		     returns while failing to try lock acquire rq->lock
		 need_resched is not set

o	CPU5 calls  rcu_idle_enter() and as need_resched is not set, goes to
	idle (schedule() is not called).

o	CPU 1 reports RCU stall.

Given that resched_cpu() is now used only by RCU, this commit fixes the
assumption by making resched_cpu() unconditional.

Reported-by: Neeraj Upadhyay <neeraju@codeaurora.org>
Suggested-by: Neeraj Upadhyay <neeraju@codeaurora.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
---
 kernel/sched/core.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index d17c5da523a0..8fa7b6f9e19b 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -505,8 +505,7 @@ void resched_cpu(int cpu)
 	struct rq *rq = cpu_rq(cpu);
 	unsigned long flags;
 
-	if (!raw_spin_trylock_irqsave(&rq->lock, flags))
-		return;
+	raw_spin_lock_irqsave(&rq->lock, flags);
 	resched_curr(rq);
 	raw_spin_unlock_irqrestore(&rq->lock, flags);
 }
-- 
2.5.2

^ permalink raw reply related

* [PATCH 2/3] mm: slabinfo: dump CONFIG_SLABINFO
From: Yang Shi @ 2017-10-04 21:29 UTC (permalink / raw)
  To: cl, penberg, rientjes, iamjoonsoo.kim, akpm, mhocko
  Cc: Yang Shi, linux-mm, linux-kernel
In-Reply-To: <1507152550-46205-1-git-send-email-yang.s@alibaba-inc.com>

According to the discussion with Christoph [1], it sounds it is pointless
to keep CONFIG_SLABINFO around.

This patch just remove CONFIG_SLABINFO config option, but /proc/slabinfo
is still available.

[1] https://marc.info/?l=linux-kernel&m=150695909709711&w=2

Signed-off-by: Yang Shi <yang.s@alibaba-inc.com>
---
 init/Kconfig     | 6 ------
 mm/memcontrol.c  | 2 --
 mm/slab.c        | 2 --
 mm/slab_common.c | 3 ---
 mm/slub.c        | 2 --
 5 files changed, 15 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index 78cb246..5d3c80a 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1657,12 +1657,6 @@ config HAVE_GENERIC_DMA_COHERENT
 	bool
 	default n
 
-config SLABINFO
-	bool
-	depends on PROC_FS
-	depends on SLAB || SLUB_DEBUG
-	default y
-
 config RT_MUTEXES
 	bool
 
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index d5f3a62..c741063 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4049,7 +4049,6 @@ static ssize_t memcg_write_event_control(struct kernfs_open_file *of,
 		.write = mem_cgroup_reset,
 		.read_u64 = mem_cgroup_read_u64,
 	},
-#ifdef CONFIG_SLABINFO
 	{
 		.name = "kmem.slabinfo",
 		.seq_start = memcg_slab_start,
@@ -4057,7 +4056,6 @@ static ssize_t memcg_write_event_control(struct kernfs_open_file *of,
 		.seq_stop = memcg_slab_stop,
 		.seq_show = memcg_slab_show,
 	},
-#endif
 	{
 		.name = "kmem.tcp.limit_in_bytes",
 		.private = MEMFILE_PRIVATE(_TCP, RES_LIMIT),
diff --git a/mm/slab.c b/mm/slab.c
index 04dec48..5743a51 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -4096,7 +4096,6 @@ static void cache_reap(struct work_struct *w)
 	schedule_delayed_work(work, round_jiffies_relative(REAPTIMEOUT_AC));
 }
 
-#ifdef CONFIG_SLABINFO
 void get_slabinfo(struct kmem_cache *cachep, struct slabinfo *sinfo)
 {
 	unsigned long active_objs, num_objs, active_slabs;
@@ -4404,7 +4403,6 @@ static int __init slab_proc_init(void)
 	return 0;
 }
 module_init(slab_proc_init);
-#endif
 
 #ifdef CONFIG_HARDENED_USERCOPY
 /*
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 8016459..c1629cb 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -1183,8 +1183,6 @@ void cache_random_seq_destroy(struct kmem_cache *cachep)
 }
 #endif /* CONFIG_SLAB_FREELIST_RANDOM */
 
-#ifdef CONFIG_SLABINFO
-
 #ifdef CONFIG_SLAB
 #define SLABINFO_RIGHTS (S_IWUSR | S_IRUSR)
 #else
@@ -1354,7 +1352,6 @@ static int __init slab_proc_init(void)
 	return 0;
 }
 module_init(slab_proc_init);
-#endif /* CONFIG_SLABINFO */
 
 static __always_inline void *__do_krealloc(const void *p, size_t new_size,
 					   gfp_t flags)
diff --git a/mm/slub.c b/mm/slub.c
index 163352c..74a8776 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -5851,7 +5851,6 @@ static int __init slab_sysfs_init(void)
 /*
  * The /proc/slabinfo ABI
  */
-#ifdef CONFIG_SLABINFO
 void get_slabinfo(struct kmem_cache *s, struct slabinfo *sinfo)
 {
 	unsigned long nr_slabs = 0;
@@ -5883,4 +5882,3 @@ ssize_t slabinfo_write(struct file *file, const char __user *buffer,
 {
 	return -EIO;
 }
-#endif /* CONFIG_SLABINFO */
-- 
1.8.3.1

^ permalink raw reply related

* [PATCH 1/3] tools: slabinfo: add "-U" option to show unreclaimable slabs only
From: Yang Shi @ 2017-10-04 21:29 UTC (permalink / raw)
  To: cl, penberg, rientjes, iamjoonsoo.kim, akpm, mhocko
  Cc: Yang Shi, linux-mm, linux-kernel
In-Reply-To: <1507152550-46205-1-git-send-email-yang.s@alibaba-inc.com>

Add "-U" option to show unreclaimable slabs only.

"-U" and "-S" together can tell us what unreclaimable slabs use the most
memory to help debug huge unreclaimable slabs issue.

Signed-off-by: Yang Shi <yang.s@alibaba-inc.com>
Acked-by: Christoph Lameter <cl@linux.com>
Acked-by: David Rientjes <rientjes@google.com>
---
 tools/vm/slabinfo.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/tools/vm/slabinfo.c b/tools/vm/slabinfo.c
index b9d34b3..de8fa11 100644
--- a/tools/vm/slabinfo.c
+++ b/tools/vm/slabinfo.c
@@ -83,6 +83,7 @@ struct aliasinfo {
 int sort_loss;
 int extended_totals;
 int show_bytes;
+int unreclaim_only;
 
 /* Debug options */
 int sanity;
@@ -132,6 +133,7 @@ static void usage(void)
 		"-L|--Loss              Sort by loss\n"
 		"-X|--Xtotals           Show extended summary information\n"
 		"-B|--Bytes             Show size in bytes\n"
+		"-U|--Unreclaim		Show unreclaimable slabs only\n"
 		"\nValid debug options (FZPUT may be combined)\n"
 		"a / A          Switch on all debug options (=FZUP)\n"
 		"-              Switch off all debug options\n"
@@ -568,6 +570,9 @@ static void slabcache(struct slabinfo *s)
 	if (strcmp(s->name, "*") == 0)
 		return;
 
+	if (unreclaim_only && s->reclaim_account)
+		return;
+
 	if (actual_slabs == 1) {
 		report(s);
 		return;
@@ -1346,6 +1351,7 @@ struct option opts[] = {
 	{ "Loss", no_argument, NULL, 'L'},
 	{ "Xtotals", no_argument, NULL, 'X'},
 	{ "Bytes", no_argument, NULL, 'B'},
+	{ "Unreclaim", no_argument, NULL, 'U'},
 	{ NULL, 0, NULL, 0 }
 };
 
@@ -1357,7 +1363,7 @@ int main(int argc, char *argv[])
 
 	page_size = getpagesize();
 
-	while ((c = getopt_long(argc, argv, "aAd::Defhil1noprstvzTSN:LXB",
+	while ((c = getopt_long(argc, argv, "aAd::Defhil1noprstvzTSN:LXBU",
 						opts, NULL)) != -1)
 		switch (c) {
 		case '1':
@@ -1438,6 +1444,9 @@ int main(int argc, char *argv[])
 		case 'B':
 			show_bytes = 1;
 			break;
+		case 'U':
+			unreclaim_only = 1;
+			break;
 		default:
 			fatal("%s: Invalid option '%c'\n", argv[0], optopt);
 
-- 
1.8.3.1

^ permalink raw reply related

* [PATCH 3/3] mm: oom: show unreclaimable slab info when unreclaimable slabs > user memory
From: Yang Shi @ 2017-10-04 21:29 UTC (permalink / raw)
  To: cl, penberg, rientjes, iamjoonsoo.kim, akpm, mhocko
  Cc: Yang Shi, linux-mm, linux-kernel
In-Reply-To: <1507152550-46205-1-git-send-email-yang.s@alibaba-inc.com>

Kernel may panic when oom happens without killable process sometimes it
is caused by huge unreclaimable slabs used by kernel.

Although kdump could help debug such problem, however, kdump is not
available on all architectures and it might be malfunction sometime.
And, since kernel already panic it is worthy capturing such information
in dmesg to aid touble shooting.

Print out unreclaimable slab info (used size and total size) which
actual memory usage is not zero (num_objs * size != 0) when
unreclaimable slabs amount is greater than total user memory (LRU
pages).

The output looks like:

Unreclaimable slab info:
Name                      Used          Total
rpc_buffers               31KB         31KB
rpc_tasks                  7KB          7KB
ebitmap_node            1964KB       1964KB
avtab_node              5024KB       5024KB
xfs_buf                 1402KB       1402KB
xfs_ili                  134KB        134KB
xfs_efi_item             115KB        115KB
xfs_efd_item             115KB        115KB
xfs_buf_item             134KB        134KB
xfs_log_item_desc        342KB        342KB
xfs_trans               1412KB       1412KB
xfs_ifork                212KB        212KB

Signed-off-by: Yang Shi <yang.s@alibaba-inc.com>
---
 mm/oom_kill.c    | 27 +++++++++++++++++++++++++--
 mm/slab.h        |  2 ++
 mm/slab_common.c | 35 +++++++++++++++++++++++++++++++++++
 3 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index dee0f75..3023919 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -44,6 +44,7 @@
 
 #include <asm/tlb.h>
 #include "internal.h"
+#include "slab.h"
 
 #define CREATE_TRACE_POINTS
 #include <trace/events/oom.h>
@@ -161,6 +162,25 @@ static bool oom_unkillable_task(struct task_struct *p,
 	return false;
 }
 
+/*
+ * Print out unreclaimble slabs info when unreclaimable slabs amount is greater
+ * than all user memory (LRU pages)
+ */
+static bool is_dump_unreclaim_slabs(void)
+{
+	unsigned long nr_lru;
+
+	nr_lru = global_node_page_state(NR_ACTIVE_ANON) +
+		 global_node_page_state(NR_INACTIVE_ANON) +
+		 global_node_page_state(NR_ACTIVE_FILE) +
+		 global_node_page_state(NR_INACTIVE_FILE) +
+		 global_node_page_state(NR_ISOLATED_ANON) +
+		 global_node_page_state(NR_ISOLATED_FILE) +
+		 global_node_page_state(NR_UNEVICTABLE);
+
+	return (global_node_page_state(NR_SLAB_UNRECLAIMABLE) > nr_lru);
+}
+
 /**
  * oom_badness - heuristic function to determine which candidate task to kill
  * @p: task struct of which task we should calculate
@@ -420,10 +440,13 @@ static void dump_header(struct oom_control *oc, struct task_struct *p)
 
 	cpuset_print_current_mems_allowed();
 	dump_stack();
-	if (oc->memcg)
+	if (is_memcg_oom(oc))
 		mem_cgroup_print_oom_info(oc->memcg, p);
-	else
+	else {
 		show_mem(SHOW_MEM_FILTER_NODES, oc->nodemask);
+		if (is_dump_unreclaim_slabs())
+			dump_unreclaimable_slab();
+	}
 	if (sysctl_oom_dump_tasks)
 		dump_tasks(oc->memcg, oc->nodemask);
 }
diff --git a/mm/slab.h b/mm/slab.h
index 0733628..6fc4d5d 100644
--- a/mm/slab.h
+++ b/mm/slab.h
@@ -505,6 +505,8 @@ static inline struct kmem_cache_node *get_node(struct kmem_cache *s, int node)
 void memcg_slab_stop(struct seq_file *m, void *p);
 int memcg_slab_show(struct seq_file *m, void *p);
 
+void dump_unreclaimable_slab(void);
+
 void ___cache_free(struct kmem_cache *cache, void *x, unsigned long addr);
 
 #ifdef CONFIG_SLAB_FREELIST_RANDOM
diff --git a/mm/slab_common.c b/mm/slab_common.c
index c1629cb..5c8fac5 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -1278,6 +1278,41 @@ static int slab_show(struct seq_file *m, void *p)
 	return 0;
 }
 
+void dump_unreclaimable_slab(void)
+{
+	struct kmem_cache *s, *s2;
+	struct slabinfo sinfo;
+
+	/*
+	 * Here acquiring slab_mutex is risky since we don't prefer to get
+	 * sleep in oom path. But, without mutex hold, it may introduce a
+	 * risk of crash.
+	 * Use mutex_trylock to protect the list traverse, dump nothing
+	 * without acquiring the mutex.
+	 */
+	if (!mutex_trylock(&slab_mutex)) {
+		pr_warn("excessive unreclaimable slab but cannot dump stats\n");
+		return;
+	}
+
+	pr_info("Unreclaimable slab info:\n");
+	pr_info("Name                      Used          Total\n");
+
+	list_for_each_entry_safe(s, s2, &slab_caches, list) {
+		if (!is_root_cache(s) || (s->flags & SLAB_RECLAIM_ACCOUNT))
+			continue;
+
+		memset(&sinfo, 0, sizeof(sinfo));
+		get_slabinfo(s, &sinfo);
+
+		if (sinfo.num_objs > 0)
+			pr_info("%-17s %10luKB %10luKB\n", cache_name(s),
+				(sinfo.active_objs * s->size) / 1024,
+				(sinfo.num_objs * s->size) / 1024);
+	}
+	mutex_unlock(&slab_mutex);
+}
+
 #if defined(CONFIG_MEMCG) && !defined(CONFIG_SLOB)
 void *memcg_slab_start(struct seq_file *m, loff_t *pos)
 {
-- 
1.8.3.1

^ permalink raw reply related

* [PATCH 0/3 v10] oom: capture unreclaimable slab info in oom message
From: Yang Shi @ 2017-10-04 21:29 UTC (permalink / raw)
  To: cl, penberg, rientjes, iamjoonsoo.kim, akpm, mhocko
  Cc: Yang Shi, linux-mm, linux-kernel


Recently we ran into a oom issue, kernel panic due to no killable process.
The dmesg shows huge unreclaimable slabs used almost 100% memory, but kdump doesn't capture vmcore due to some reason.

So, it may sound better to capture unreclaimable slab info in oom message when kernel panic to aid trouble shooting and cover the corner case.
Since kernel already panic, so capturing more information sounds worthy and doesn't bother normal oom killer.

With the patchset, tools/vm/slabinfo has a new option, "-U", to show unreclaimable slab only.

And, oom will print all non zero (num_objs * size != 0) unreclaimable slabs in oom killer message.

For details, please see the commit log for each commit.

Changelog v9 a??> v10:
* Adopted the suggestion from Michal to just dump unreclaimable slab stats when !is_memcg_oom
* Adopted the suggestion from Michal to print warning when unreclaimable slabs dump cana??t acquire the mutex

Changelog v8 a??> v9:
* Adopted Tetsuoa??s suggestion to protect global slab list traverse with mutex_trylock() to prevent from sleeping. Without the mutex acquired unreclaimable slbas will not be dumped.
* Adopted the suggestion from Christoph to dump CONFIG_SLABINFO since it is pointless to keep it.
* Rebased to 4.13-rc3

Changelog v7 a??> v8:
* Adopted Michala??s suggestion to dump unreclaim slab info when unreclaimable slabs amount > total user memory. Not only in oom panic path.

Changelog v6 -> v7:
* Added unreclaim_slabs_oom_ratio proc knob, unreclaimable slabs info will be dumped when unreclaimable slabs amount : all user memory > the ratio

Changelog v5 a??> v6:
* Fixed a checkpatch.pl warning for patch #2

Changelog v4 a??> v5:
* Solved the comments from David
* Build test SLABINFO = n

Changelog v3 a??> v4:
* Solved the comments from David
* Added Davida??s Acked-by in patch 1

Changelog v2 a??> v3:
* Show used size and total size of each kmem cache per Davida??s comment

Changelog v1 a??> v2:
* Removed the original patch 1 (a??mm: slab: output reclaimable flag in /proc/slabinfoa??) since Christoph suggested it might break the compatibility and /proc/slabinfo is legacy
* Added Christopha??s Acked-by
* Removed acquiring slab_mutex per Tetsuoa??s comment


Yang Shi (3):
      tools: slabinfo: add "-U" option to show unreclaimable slabs only
      mm: slabinfo: dump CONFIG_SLABINFO
      mm: oom: show unreclaimable slab info when unreclaimable slabs > user memory

 init/Kconfig        |  6 ------
 mm/memcontrol.c     |  2 --
 mm/oom_kill.c       | 27 +++++++++++++++++++++++++--
 mm/slab.c           |  2 --
 mm/slab.h           |  2 ++
 mm/slab_common.c    | 38 +++++++++++++++++++++++++++++++++++---
 mm/slub.c           |  2 --
 tools/vm/slabinfo.c | 11 ++++++++++-
 8 files changed, 72 insertions(+), 18 deletions(-)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply

* [PATCH 1/3] tools: slabinfo: add "-U" option to show unreclaimable slabs only
From: Yang Shi @ 2017-10-04 21:29 UTC (permalink / raw)
  To: cl, penberg, rientjes, iamjoonsoo.kim, akpm, mhocko
  Cc: Yang Shi, linux-mm, linux-kernel
In-Reply-To: <1507152550-46205-1-git-send-email-yang.s@alibaba-inc.com>

Add "-U" option to show unreclaimable slabs only.

"-U" and "-S" together can tell us what unreclaimable slabs use the most
memory to help debug huge unreclaimable slabs issue.

Signed-off-by: Yang Shi <yang.s@alibaba-inc.com>
Acked-by: Christoph Lameter <cl@linux.com>
Acked-by: David Rientjes <rientjes@google.com>
---
 tools/vm/slabinfo.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/tools/vm/slabinfo.c b/tools/vm/slabinfo.c
index b9d34b3..de8fa11 100644
--- a/tools/vm/slabinfo.c
+++ b/tools/vm/slabinfo.c
@@ -83,6 +83,7 @@ struct aliasinfo {
 int sort_loss;
 int extended_totals;
 int show_bytes;
+int unreclaim_only;
 
 /* Debug options */
 int sanity;
@@ -132,6 +133,7 @@ static void usage(void)
 		"-L|--Loss              Sort by loss\n"
 		"-X|--Xtotals           Show extended summary information\n"
 		"-B|--Bytes             Show size in bytes\n"
+		"-U|--Unreclaim		Show unreclaimable slabs only\n"
 		"\nValid debug options (FZPUT may be combined)\n"
 		"a / A          Switch on all debug options (=FZUP)\n"
 		"-              Switch off all debug options\n"
@@ -568,6 +570,9 @@ static void slabcache(struct slabinfo *s)
 	if (strcmp(s->name, "*") == 0)
 		return;
 
+	if (unreclaim_only && s->reclaim_account)
+		return;
+
 	if (actual_slabs == 1) {
 		report(s);
 		return;
@@ -1346,6 +1351,7 @@ struct option opts[] = {
 	{ "Loss", no_argument, NULL, 'L'},
 	{ "Xtotals", no_argument, NULL, 'X'},
 	{ "Bytes", no_argument, NULL, 'B'},
+	{ "Unreclaim", no_argument, NULL, 'U'},
 	{ NULL, 0, NULL, 0 }
 };
 
@@ -1357,7 +1363,7 @@ int main(int argc, char *argv[])
 
 	page_size = getpagesize();
 
-	while ((c = getopt_long(argc, argv, "aAd::Defhil1noprstvzTSN:LXB",
+	while ((c = getopt_long(argc, argv, "aAd::Defhil1noprstvzTSN:LXBU",
 						opts, NULL)) != -1)
 		switch (c) {
 		case '1':
@@ -1438,6 +1444,9 @@ int main(int argc, char *argv[])
 		case 'B':
 			show_bytes = 1;
 			break;
+		case 'U':
+			unreclaim_only = 1;
+			break;
 		default:
 			fatal("%s: Invalid option '%c'\n", argv[0], optopt);
 
-- 
1.8.3.1

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply related

* [PATCH 0/3 v10] oom: capture unreclaimable slab info in oom message
From: Yang Shi @ 2017-10-04 21:29 UTC (permalink / raw)
  To: cl, penberg, rientjes, iamjoonsoo.kim, akpm, mhocko
  Cc: Yang Shi, linux-mm, linux-kernel


Recently we ran into a oom issue, kernel panic due to no killable process.
The dmesg shows huge unreclaimable slabs used almost 100% memory, but kdump doesn't capture vmcore due to some reason.

So, it may sound better to capture unreclaimable slab info in oom message when kernel panic to aid trouble shooting and cover the corner case.
Since kernel already panic, so capturing more information sounds worthy and doesn't bother normal oom killer.

With the patchset, tools/vm/slabinfo has a new option, "-U", to show unreclaimable slab only.

And, oom will print all non zero (num_objs * size != 0) unreclaimable slabs in oom killer message.

For details, please see the commit log for each commit.

Changelog v9 —> v10:
* Adopted the suggestion from Michal to just dump unreclaimable slab stats when !is_memcg_oom
* Adopted the suggestion from Michal to print warning when unreclaimable slabs dump can’t acquire the mutex

Changelog v8 —> v9:
* Adopted Tetsuo’s suggestion to protect global slab list traverse with mutex_trylock() to prevent from sleeping. Without the mutex acquired unreclaimable slbas will not be dumped.
* Adopted the suggestion from Christoph to dump CONFIG_SLABINFO since it is pointless to keep it.
* Rebased to 4.13-rc3

Changelog v7 —> v8:
* Adopted Michal’s suggestion to dump unreclaim slab info when unreclaimable slabs amount > total user memory. Not only in oom panic path.

Changelog v6 -> v7:
* Added unreclaim_slabs_oom_ratio proc knob, unreclaimable slabs info will be dumped when unreclaimable slabs amount : all user memory > the ratio

Changelog v5 —> v6:
* Fixed a checkpatch.pl warning for patch #2

Changelog v4 —> v5:
* Solved the comments from David
* Build test SLABINFO = n

Changelog v3 —> v4:
* Solved the comments from David
* Added David’s Acked-by in patch 1

Changelog v2 —> v3:
* Show used size and total size of each kmem cache per David’s comment

Changelog v1 —> v2:
* Removed the original patch 1 (“mm: slab: output reclaimable flag in /proc/slabinfo”) since Christoph suggested it might break the compatibility and /proc/slabinfo is legacy
* Added Christoph’s Acked-by
* Removed acquiring slab_mutex per Tetsuo’s comment


Yang Shi (3):
      tools: slabinfo: add "-U" option to show unreclaimable slabs only
      mm: slabinfo: dump CONFIG_SLABINFO
      mm: oom: show unreclaimable slab info when unreclaimable slabs > user memory

 init/Kconfig        |  6 ------
 mm/memcontrol.c     |  2 --
 mm/oom_kill.c       | 27 +++++++++++++++++++++++++--
 mm/slab.c           |  2 --
 mm/slab.h           |  2 ++
 mm/slab_common.c    | 38 +++++++++++++++++++++++++++++++++++---
 mm/slub.c           |  2 --
 tools/vm/slabinfo.c | 11 ++++++++++-
 8 files changed, 72 insertions(+), 18 deletions(-)

^ permalink raw reply

* Re: [3rdparty][PATCH] Add wic image support
From: TEXIER Pierre-Jean @ 2017-10-04 21:29 UTC (permalink / raw)
  To: Otavio Salvador; +Cc: meta-freescale@yoctoproject.org
In-Reply-To: <CAP9ODKo_EdgsjUW_xofPLPDokD7hwKN6u4RFcwZAVCZKNtKxGg@mail.gmail.com>

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

Hi Otavio,

Thanks, it works from my side.
I just sent a new patch without IMAGE_BOOT_FILES.

Pierre-Jean

2017-10-04 22:42 GMT+02:00 Otavio Salvador <otavio.salvador@ossystems.com.br
>:

> Hello,
>
> On Wed, Oct 4, 2017 at 5:21 PM, Pierre-Jean TEXIER <texier.pj2@gmail.com>
> wrote:
> > Signed-off-by: Pierre-Jean TEXIER <texier.pj2@gmail.com>
> > ---
> >  conf/machine/imx7s-warp.conf | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/conf/machine/imx7s-warp.conf b/conf/machine/imx7s-warp.conf
> > index 7a23fd6..87a740c 100644
> > --- a/conf/machine/imx7s-warp.conf
> > +++ b/conf/machine/imx7s-warp.conf
> > @@ -18,4 +18,12 @@ PREFERRED_PROVIDER_virtual/kernel ?= "linux-warp7"
> >  UBOOT_CONFIG ??= "sd"
> >  UBOOT_CONFIG[sd] = "warp7_secure_defconfig,sdcard"
> >
> > +# wic
> > +IMAGE_FSTYPES = "wic.gz"
> > +IMAGE_BOOT_FILES = " \
> > +       ${KERNEL_IMAGETYPE} \
> > +       ${KERNEL_IMAGETYPE}-imx7s-warp.dtb;imx7s-warp.dtb \
> > +"
>
> I just sent a generic definition for the IMAGE_BOOT_FILES for
> imx-base.inc. Please check if it works for you so we can avoid
> duplicating it over all machines.
>
> > +WKS_FILE ?= "imx-uboot-bootpart.wks"
> > +
> >  MACHINE_EXTRA_RRECOMMENDS += "firmware-imx-brcm"
> > --
> > 2.7.4
> >
> > --
> > _______________________________________________
> > meta-freescale mailing list
> > meta-freescale@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/meta-freescale
>
>
>
> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
>

[-- Attachment #2: Type: text/html, Size: 3095 bytes --]

^ permalink raw reply

* [PATCH 2/3] mm: slabinfo: dump CONFIG_SLABINFO
From: Yang Shi @ 2017-10-04 21:29 UTC (permalink / raw)
  To: cl, penberg, rientjes, iamjoonsoo.kim, akpm, mhocko
  Cc: Yang Shi, linux-mm, linux-kernel
In-Reply-To: <1507152550-46205-1-git-send-email-yang.s@alibaba-inc.com>

According to the discussion with Christoph [1], it sounds it is pointless
to keep CONFIG_SLABINFO around.

This patch just remove CONFIG_SLABINFO config option, but /proc/slabinfo
is still available.

[1] https://marc.info/?l=linux-kernel&m=150695909709711&w=2

Signed-off-by: Yang Shi <yang.s@alibaba-inc.com>
---
 init/Kconfig     | 6 ------
 mm/memcontrol.c  | 2 --
 mm/slab.c        | 2 --
 mm/slab_common.c | 3 ---
 mm/slub.c        | 2 --
 5 files changed, 15 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index 78cb246..5d3c80a 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1657,12 +1657,6 @@ config HAVE_GENERIC_DMA_COHERENT
 	bool
 	default n
 
-config SLABINFO
-	bool
-	depends on PROC_FS
-	depends on SLAB || SLUB_DEBUG
-	default y
-
 config RT_MUTEXES
 	bool
 
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index d5f3a62..c741063 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4049,7 +4049,6 @@ static ssize_t memcg_write_event_control(struct kernfs_open_file *of,
 		.write = mem_cgroup_reset,
 		.read_u64 = mem_cgroup_read_u64,
 	},
-#ifdef CONFIG_SLABINFO
 	{
 		.name = "kmem.slabinfo",
 		.seq_start = memcg_slab_start,
@@ -4057,7 +4056,6 @@ static ssize_t memcg_write_event_control(struct kernfs_open_file *of,
 		.seq_stop = memcg_slab_stop,
 		.seq_show = memcg_slab_show,
 	},
-#endif
 	{
 		.name = "kmem.tcp.limit_in_bytes",
 		.private = MEMFILE_PRIVATE(_TCP, RES_LIMIT),
diff --git a/mm/slab.c b/mm/slab.c
index 04dec48..5743a51 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -4096,7 +4096,6 @@ static void cache_reap(struct work_struct *w)
 	schedule_delayed_work(work, round_jiffies_relative(REAPTIMEOUT_AC));
 }
 
-#ifdef CONFIG_SLABINFO
 void get_slabinfo(struct kmem_cache *cachep, struct slabinfo *sinfo)
 {
 	unsigned long active_objs, num_objs, active_slabs;
@@ -4404,7 +4403,6 @@ static int __init slab_proc_init(void)
 	return 0;
 }
 module_init(slab_proc_init);
-#endif
 
 #ifdef CONFIG_HARDENED_USERCOPY
 /*
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 8016459..c1629cb 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -1183,8 +1183,6 @@ void cache_random_seq_destroy(struct kmem_cache *cachep)
 }
 #endif /* CONFIG_SLAB_FREELIST_RANDOM */
 
-#ifdef CONFIG_SLABINFO
-
 #ifdef CONFIG_SLAB
 #define SLABINFO_RIGHTS (S_IWUSR | S_IRUSR)
 #else
@@ -1354,7 +1352,6 @@ static int __init slab_proc_init(void)
 	return 0;
 }
 module_init(slab_proc_init);
-#endif /* CONFIG_SLABINFO */
 
 static __always_inline void *__do_krealloc(const void *p, size_t new_size,
 					   gfp_t flags)
diff --git a/mm/slub.c b/mm/slub.c
index 163352c..74a8776 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -5851,7 +5851,6 @@ static int __init slab_sysfs_init(void)
 /*
  * The /proc/slabinfo ABI
  */
-#ifdef CONFIG_SLABINFO
 void get_slabinfo(struct kmem_cache *s, struct slabinfo *sinfo)
 {
 	unsigned long nr_slabs = 0;
@@ -5883,4 +5882,3 @@ ssize_t slabinfo_write(struct file *file, const char __user *buffer,
 {
 	return -EIO;
 }
-#endif /* CONFIG_SLABINFO */
-- 
1.8.3.1

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply related

* [PATCH tip/core/rcu 0/9] Miscellaneous fixes for v4.15
From: Paul E. McKenney @ 2017-10-04 21:29 UTC (permalink / raw)
  To: linux-kernel
  Cc: mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh,
	tglx, peterz, rostedt, dhowells, edumazet, fweisbec, oleg

Hello!

This series contains the following miscellaneous fixes:

1.	Provide GP ordering in face of migrations and delays.

2.	Fix up pending cbs check in rcu_prepare_for_idle(), courtesy
	of Neeraj Upadhyay.

3.	Create call_rcu_tasks() kthread at boot time.

4.	Map irq_work_on_queue() to irq_work_on() in !SMP.

5.	Add parameters to SRCU docbook comments.

6.	Make resched_cpu() unconditional.

7.	Pretend ->boost_mtx acquired legitimately for lockdep's benefit.

8.	Add extended-quiescent-state testing advice.

9.	Include rcupdate.h into kernel/rcu/segcblist, courtesy of
	Sebastian Andrzej Siewior.

							Thanx, Paul

------------------------------------------------------------------------

 include/linux/irq_work.h   |    3 ---
 include/linux/srcu.h       |    1 +
 kernel/irq_work.c          |    9 ++++++---
 kernel/rcu/rcu_segcblist.c |    1 +
 kernel/rcu/srcutree.c      |    2 +-
 kernel/rcu/tree.c          |   30 ++++++++++++++++++++++++++++++
 kernel/rcu/tree_plugin.h   |    7 +++++--
 kernel/rcu/update.c        |   34 +++++++++++++++-------------------
 kernel/sched/core.c        |    3 +--
 9 files changed, 60 insertions(+), 30 deletions(-)

^ permalink raw reply

* [PATCH 3/3] mm: oom: show unreclaimable slab info when unreclaimable slabs > user memory
From: Yang Shi @ 2017-10-04 21:29 UTC (permalink / raw)
  To: cl, penberg, rientjes, iamjoonsoo.kim, akpm, mhocko
  Cc: Yang Shi, linux-mm, linux-kernel
In-Reply-To: <1507152550-46205-1-git-send-email-yang.s@alibaba-inc.com>

Kernel may panic when oom happens without killable process sometimes it
is caused by huge unreclaimable slabs used by kernel.

Although kdump could help debug such problem, however, kdump is not
available on all architectures and it might be malfunction sometime.
And, since kernel already panic it is worthy capturing such information
in dmesg to aid touble shooting.

Print out unreclaimable slab info (used size and total size) which
actual memory usage is not zero (num_objs * size != 0) when
unreclaimable slabs amount is greater than total user memory (LRU
pages).

The output looks like:

Unreclaimable slab info:
Name                      Used          Total
rpc_buffers               31KB         31KB
rpc_tasks                  7KB          7KB
ebitmap_node            1964KB       1964KB
avtab_node              5024KB       5024KB
xfs_buf                 1402KB       1402KB
xfs_ili                  134KB        134KB
xfs_efi_item             115KB        115KB
xfs_efd_item             115KB        115KB
xfs_buf_item             134KB        134KB
xfs_log_item_desc        342KB        342KB
xfs_trans               1412KB       1412KB
xfs_ifork                212KB        212KB

Signed-off-by: Yang Shi <yang.s@alibaba-inc.com>
---
 mm/oom_kill.c    | 27 +++++++++++++++++++++++++--
 mm/slab.h        |  2 ++
 mm/slab_common.c | 35 +++++++++++++++++++++++++++++++++++
 3 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index dee0f75..3023919 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -44,6 +44,7 @@
 
 #include <asm/tlb.h>
 #include "internal.h"
+#include "slab.h"
 
 #define CREATE_TRACE_POINTS
 #include <trace/events/oom.h>
@@ -161,6 +162,25 @@ static bool oom_unkillable_task(struct task_struct *p,
 	return false;
 }
 
+/*
+ * Print out unreclaimble slabs info when unreclaimable slabs amount is greater
+ * than all user memory (LRU pages)
+ */
+static bool is_dump_unreclaim_slabs(void)
+{
+	unsigned long nr_lru;
+
+	nr_lru = global_node_page_state(NR_ACTIVE_ANON) +
+		 global_node_page_state(NR_INACTIVE_ANON) +
+		 global_node_page_state(NR_ACTIVE_FILE) +
+		 global_node_page_state(NR_INACTIVE_FILE) +
+		 global_node_page_state(NR_ISOLATED_ANON) +
+		 global_node_page_state(NR_ISOLATED_FILE) +
+		 global_node_page_state(NR_UNEVICTABLE);
+
+	return (global_node_page_state(NR_SLAB_UNRECLAIMABLE) > nr_lru);
+}
+
 /**
  * oom_badness - heuristic function to determine which candidate task to kill
  * @p: task struct of which task we should calculate
@@ -420,10 +440,13 @@ static void dump_header(struct oom_control *oc, struct task_struct *p)
 
 	cpuset_print_current_mems_allowed();
 	dump_stack();
-	if (oc->memcg)
+	if (is_memcg_oom(oc))
 		mem_cgroup_print_oom_info(oc->memcg, p);
-	else
+	else {
 		show_mem(SHOW_MEM_FILTER_NODES, oc->nodemask);
+		if (is_dump_unreclaim_slabs())
+			dump_unreclaimable_slab();
+	}
 	if (sysctl_oom_dump_tasks)
 		dump_tasks(oc->memcg, oc->nodemask);
 }
diff --git a/mm/slab.h b/mm/slab.h
index 0733628..6fc4d5d 100644
--- a/mm/slab.h
+++ b/mm/slab.h
@@ -505,6 +505,8 @@ static inline struct kmem_cache_node *get_node(struct kmem_cache *s, int node)
 void memcg_slab_stop(struct seq_file *m, void *p);
 int memcg_slab_show(struct seq_file *m, void *p);
 
+void dump_unreclaimable_slab(void);
+
 void ___cache_free(struct kmem_cache *cache, void *x, unsigned long addr);
 
 #ifdef CONFIG_SLAB_FREELIST_RANDOM
diff --git a/mm/slab_common.c b/mm/slab_common.c
index c1629cb..5c8fac5 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -1278,6 +1278,41 @@ static int slab_show(struct seq_file *m, void *p)
 	return 0;
 }
 
+void dump_unreclaimable_slab(void)
+{
+	struct kmem_cache *s, *s2;
+	struct slabinfo sinfo;
+
+	/*
+	 * Here acquiring slab_mutex is risky since we don't prefer to get
+	 * sleep in oom path. But, without mutex hold, it may introduce a
+	 * risk of crash.
+	 * Use mutex_trylock to protect the list traverse, dump nothing
+	 * without acquiring the mutex.
+	 */
+	if (!mutex_trylock(&slab_mutex)) {
+		pr_warn("excessive unreclaimable slab but cannot dump stats\n");
+		return;
+	}
+
+	pr_info("Unreclaimable slab info:\n");
+	pr_info("Name                      Used          Total\n");
+
+	list_for_each_entry_safe(s, s2, &slab_caches, list) {
+		if (!is_root_cache(s) || (s->flags & SLAB_RECLAIM_ACCOUNT))
+			continue;
+
+		memset(&sinfo, 0, sizeof(sinfo));
+		get_slabinfo(s, &sinfo);
+
+		if (sinfo.num_objs > 0)
+			pr_info("%-17s %10luKB %10luKB\n", cache_name(s),
+				(sinfo.active_objs * s->size) / 1024,
+				(sinfo.num_objs * s->size) / 1024);
+	}
+	mutex_unlock(&slab_mutex);
+}
+
 #if defined(CONFIG_MEMCG) && !defined(CONFIG_SLOB)
 void *memcg_slab_start(struct seq_file *m, loff_t *pos)
 {
-- 
1.8.3.1

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply related

* Re: [RFC] mmap(MAP_CONTIG)
From: Laura Abbott @ 2017-10-04 21:29 UTC (permalink / raw)
  To: Mike Kravetz, Michal Nazarewicz, linux-mm, linux-kernel,
	linux-api
  Cc: Marek Szyprowski, Aneesh Kumar K.V, Joonsoo Kim, Guy Shattah,
	Christoph Lameter
In-Reply-To: <c00b355a-cfb7-a4e0-56a3-01430dc9e9f5@oracle.com>

On 10/04/2017 10:08 AM, Mike Kravetz wrote:
> On 10/04/2017 04:54 AM, Michal Nazarewicz wrote:
>> On Tue, Oct 03 2017, Mike Kravetz wrote:
>>> At Plumbers this year, Guy Shattah and Christoph Lameter gave a presentation
>>> titled 'User space contiguous memory allocation for DMA' [1].  The slides
>>> point out the performance benefits of devices that can take advantage of
>>> larger physically contiguous areas.
>>
>> Issue I have is that kind of memory needed may depend on a device.  Some
>> may require contiguous blocks.  Some may support scatter-gather.  Some
>> may be behind IO-MMU and not care either way.
>>
>> Furthermore, I feel déjà vu.  Wasn’t dmabuf supposed to address this
>> issue?
> 
> Thanks Michal,
> 
> I was unaware of dmabuf and am just now looking at capabilities.  The
> question is whether or not the IB driver writers requesting mmap(MAP_CONTIG)
> functionality could make use of dmabuf.  That is out of my are of expertise,
> so I will let them reply.
> 

I don't think dmabuf as it exists today would help anything here.
It's designed to share buffers via fd but you still need some
place/driver to actually get the allocation and then export it
since there isn't a single interface for allocations. You could
convert drivers to take a dma_buf fd if there were appropriate
buffers available though.

Thanks,
Laura

^ permalink raw reply

* Re: [RFC] mmap(MAP_CONTIG)
From: Laura Abbott @ 2017-10-04 21:29 UTC (permalink / raw)
  To: Mike Kravetz, Michal Nazarewicz, linux-mm, linux-kernel,
	linux-api
  Cc: Marek Szyprowski, Aneesh Kumar K.V, Joonsoo Kim, Guy Shattah,
	Christoph Lameter
In-Reply-To: <c00b355a-cfb7-a4e0-56a3-01430dc9e9f5@oracle.com>

On 10/04/2017 10:08 AM, Mike Kravetz wrote:
> On 10/04/2017 04:54 AM, Michal Nazarewicz wrote:
>> On Tue, Oct 03 2017, Mike Kravetz wrote:
>>> At Plumbers this year, Guy Shattah and Christoph Lameter gave a presentation
>>> titled 'User space contiguous memory allocation for DMA' [1].  The slides
>>> point out the performance benefits of devices that can take advantage of
>>> larger physically contiguous areas.
>>
>> Issue I have is that kind of memory needed may depend on a device.  Some
>> may require contiguous blocks.  Some may support scatter-gather.  Some
>> may be behind IO-MMU and not care either way.
>>
>> Furthermore, I feel dA(C)jA  vu.  Wasna??t dmabuf supposed to address this
>> issue?
> 
> Thanks Michal,
> 
> I was unaware of dmabuf and am just now looking at capabilities.  The
> question is whether or not the IB driver writers requesting mmap(MAP_CONTIG)
> functionality could make use of dmabuf.  That is out of my are of expertise,
> so I will let them reply.
> 

I don't think dmabuf as it exists today would help anything here.
It's designed to share buffers via fd but you still need some
place/driver to actually get the allocation and then export it
since there isn't a single interface for allocations. You could
convert drivers to take a dma_buf fd if there were appropriate
buffers available though.

Thanks,
Laura

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply

* Re: [RFC] mmap(MAP_CONTIG)
From: Laura Abbott @ 2017-10-04 21:29 UTC (permalink / raw)
  To: Mike Kravetz, Michal Nazarewicz, linux-mm, linux-kernel,
	linux-api
  Cc: Marek Szyprowski, Aneesh Kumar K.V, Joonsoo Kim, Guy Shattah,
	Christoph Lameter
In-Reply-To: <c00b355a-cfb7-a4e0-56a3-01430dc9e9f5@oracle.com>

On 10/04/2017 10:08 AM, Mike Kravetz wrote:
> On 10/04/2017 04:54 AM, Michal Nazarewicz wrote:
>> On Tue, Oct 03 2017, Mike Kravetz wrote:
>>> At Plumbers this year, Guy Shattah and Christoph Lameter gave a presentation
>>> titled 'User space contiguous memory allocation for DMA' [1].  The slides
>>> point out the performance benefits of devices that can take advantage of
>>> larger physically contiguous areas.
>>
>> Issue I have is that kind of memory needed may depend on a device.  Some
>> may require contiguous blocks.  Some may support scatter-gather.  Some
>> may be behind IO-MMU and not care either way.
>>
>> Furthermore, I feel déjà vu.  Wasn’t dmabuf supposed to address this
>> issue?
> 
> Thanks Michal,
> 
> I was unaware of dmabuf and am just now looking at capabilities.  The
> question is whether or not the IB driver writers requesting mmap(MAP_CONTIG)
> functionality could make use of dmabuf.  That is out of my are of expertise,
> so I will let them reply.
> 

I don't think dmabuf as it exists today would help anything here.
It's designed to share buffers via fd but you still need some
place/driver to actually get the allocation and then export it
since there isn't a single interface for allocations. You could
convert drivers to take a dma_buf fd if there were appropriate
buffers available though.

Thanks,
Laura

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply

* [3rdparty][PATCH] imx7s-warp: Add wic image support
From: Pierre-Jean TEXIER @ 2017-10-04 21:29 UTC (permalink / raw)
  To: meta-freescale

Signed-off-by: Pierre-Jean TEXIER <texier.pj2@gmail.com>
---
 conf/machine/imx7s-warp.conf | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/conf/machine/imx7s-warp.conf b/conf/machine/imx7s-warp.conf
index 7a23fd6..68c82e6 100644
--- a/conf/machine/imx7s-warp.conf
+++ b/conf/machine/imx7s-warp.conf
@@ -18,4 +18,8 @@ PREFERRED_PROVIDER_virtual/kernel ?= "linux-warp7"
 UBOOT_CONFIG ??= "sd"
 UBOOT_CONFIG[sd] = "warp7_secure_defconfig,sdcard"
 
+# wic
+IMAGE_FSTYPES = "wic.gz"
+WKS_FILE ?= "imx-uboot-bootpart.wks"
+
 MACHINE_EXTRA_RRECOMMENDS += "firmware-imx-brcm"
-- 
2.7.4



^ permalink raw reply related

* [Buildroot] [PATCH v3] HOST_DIR/lib: symlink respectively to lib32/64
From: Matthew Weber @ 2017-10-04 21:28 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <78e41d61-c2f5-1e7f-0e45-66b497f8bff6@mind.be>

Arnout,

On Wed, Oct 4, 2017 at 3:37 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
>  Hi Matt,
>
> On 04-10-17 14:41, Matt Weber wrote:
>> Discovered the issue on a RHEL7.4 machine where
>> the cmake build dynamically selected HOST_DIR/lib64
>> as the installation path for the lzo2 library.
>>
>> Fixes failures like the following:
>> host-mtd
>> http://autobuild.buildroot.net/results/d31/d31581d2e60f35cf70312683df99c768e2ea8516/
>>
>> host-squashfs
>> http://autobuild.buildroot.net/results/d9c/d9c95231ac774ed71580754a15ebb3b121764310/
>>
>> Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
>
>  Two small nits...
>
>> ---
>> Changes
>> [Yann
>> v2 -> v3
>>  - Updated hostarch logic to check for 64bit in the name
>>    and if present create link.  This supports all archs
>>    vs just x86.
>>
>> v1 -> v2
>>  - Correct the condition used to determine host arch.
>>    (Previously used the target arch check)
>> ---
>>  Makefile | 9 ++++++++-
>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/Makefile b/Makefile
>> index 9b09589..601de1d 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -542,7 +542,7 @@ endif
>>
>>  .PHONY: dirs
>>  dirs: $(BUILD_DIR) $(STAGING_DIR) $(TARGET_DIR) \
>> -     $(HOST_DIR) $(HOST_DIR)/usr $(BINARIES_DIR)
>> +     $(HOST_DIR) $(HOST_DIR)/usr $(HOST_DIR)/lib $(BINARIES_DIR)
>>
>>  $(BUILD_DIR)/buildroot-config/auto.conf: $(BR2_CONFIG)
>>       $(MAKE1) $(EXTRAMAKEARGS) HOSTCC="$(HOSTCC_NOCCACHE)" HOSTCXX="$(HOSTCXX_NOCCACHE)" silentoldconfig
>> @@ -565,6 +565,13 @@ sdk: world
>>  $(HOST_DIR)/usr: $(HOST_DIR)
>>       @ln -snf . $@
>>
>> +$(HOST_DIR)/lib: $(HOST_DIR)
>> +     @mkdir -p $@
>> +     case $(HOSTARCH) in \
>
>  Better put @ in front here.
>
>> +             (*64) ln -s lib $(@D)/lib64;; \

So like the following but not the ln lines?  I'm not completely sure
on how @ would work with a case statement.
    @case $(HOSTARCH) in \
            (*64) ln -s lib $(@D)/lib64;; \
            (*)   ln -s lib $(@D)/lib32;; \
     esac

>
>  Probably not really important, but what would HOSTARCH be on a MIP64 n32?
>

It doesn't look like that arch could be in the HOSTARCH as it's not in
the sed filter list.

>  More importantly: it is possible that HOST_DIR/lib64 exists already but that
> HOST_DIR ends up newer - for example because a new directory (e.g. sbin) was
> created in it. Then the rule will be executed again, and a new symlink will be
> created within the lib directory. So to avoid this, use ln -snf.
>
>  To be sure, could you test with BR2_HOST_DIR set to somewhere else and also
> rebuilding?

Tested the ln -snf and the use of the alternate BR2_HOST_DIR.  Looks good.

>
>  Regards,
>  Arnout
>
>> +             (*)   ln -s lib $(@D)/lib32;; \
>> +     esac
>> +
>>  # Populating the staging with the base directories is handled by the skeleton package
>>  $(STAGING_DIR):
>>       @mkdir -p $(STAGING_DIR)
>>
>
> --
> Arnout Vandecappelle                          arnout at mind be
> Senior Embedded Software Architect            +32-16-286500
> Essensium/Mind                                http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply

* Re: [PATCH 04/13] drm/i915: Unify and export gen9+ port_clock calculation.
From: Rodrigo Vivi @ 2017-10-04 21:26 UTC (permalink / raw)
  To: Mika Kahola; +Cc: intel-gfx, Paulo Zanoni
In-Reply-To: <20171004193816.shgy7tfrdy62yqhp@intel.com>

On Wed, Oct 04, 2017 at 07:38:16PM +0000, Rodrigo Vivi wrote:
> On Wed, Oct 04, 2017 at 06:39:19AM +0000, Mika Kahola wrote:
> > On Tue, 2017-10-03 at 00:06 -0700, Rodrigo Vivi wrote:
> > > On Cannonlake the DVFS level selection depends on the
> > > port clock.
> > > 
> > > So let's re-org in a way that we can easily export without
> > > duplicating any code.
> > > 
> > > v2: Rebased on changes on previous patches
> > > 
> > > Cc: Mika Kahola <mika.kahola@intel.com>
> > > Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/intel_ddi.c | 21 ++++++++++++++++++---
> > >  drivers/gpu/drm/i915/intel_drv.h |  3 ++-
> > >  2 files changed, 20 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index 92eabb6cc1ab..ee64b1a50453 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -1297,7 +1297,7 @@ static void cnl_ddi_clock_get(struct
> > > intel_encoder *encoder,
> > >  
> > >  	pll_id = intel_get_shared_dpll_id(dev_priv, pipe_config-
> > > >shared_dpll);
> > >  
> > > -	pipe_config->port_clock = cnl_calc_pll_link(dev_priv,
> > > pll_id);
> > > +	pipe_config->port_clock = intel_ddi_port_clock(dev_priv,
> > > pll_id);
> > >  
> > >  	ddi_dotclock_get(pipe_config);
> > >  }
> > > @@ -1353,7 +1353,7 @@ static void skl_ddi_clock_get(struct
> > > intel_encoder *encoder,
> > >  
> > >  	pll_id = intel_get_shared_dpll_id(dev_priv, pipe_config-
> > > >shared_dpll);
> > >  
> > > -	pipe_config->port_clock = skl_calc_pll_link(dev_priv,
> > > pll_id);
> > > +	pipe_config->port_clock = intel_ddi_port_clock(dev_priv,
> > > pll_id);
> > >  
> > >  	ddi_dotclock_get(pipe_config);
> > >  }
> > > @@ -1437,11 +1437,26 @@ static void bxt_ddi_clock_get(struct
> > > intel_encoder *encoder,
> > >  	enum port port = intel_ddi_get_encoder_port(encoder);
> > >  	enum intel_dpll_id pll_id = port;
> > >  
> > > -	pipe_config->port_clock = bxt_calc_pll_link(dev_priv,
> > > pll_id);
> > > +	pipe_config->port_clock = intel_ddi_port_clock(dev_priv,
> > > pll_id);
> > >  
> > >  	ddi_dotclock_get(pipe_config);
> > >  }
> > >  
> > > +int intel_ddi_port_clock(struct drm_i915_private *dev_priv,
> > > +			 enum intel_dpll_id pll_id)
> > > +{
> > > +	if (IS_GEN9_BC(dev_priv)) {
> > > +		return skl_calc_pll_link(dev_priv, pll_id);
> > > +	} else if (IS_GEN9_LP(dev_priv)) {
> > > +		return bxt_calc_pll_link(dev_priv, pll_id);
> > > +	} else if (IS_CANNONLAKE(dev_priv)) {
> > > +		return cnl_calc_pll_link(dev_priv, pll_id);
> > > +	} else {
> > > +		MISSING_CASE(INTEL_GEN(dev_priv));
> > > +		return 0;
> > > +	}
> > > +}
> > Personally, I feel that we wouldn't need to unify this. We call
> > platform specific functions from this intel_ddi_port_clock() and this
> > is called from platform specific *_ddi_clock_get() routine. Why not
> > just keep all platform specific functions in one place?
> 
> Yeap, it is indeed silly to unify since we are just calling it
> from the specific functions.
> 
> Let's drop this patch ;)

oh no! wait! I was rebasing here and I'm not sure I want to drop this patch.

my OCD prefers to export general functions and leave platform specific
functions as static instead of exporting all specific platforms one.
Apparently in the future we will always need this port clock for dvfs
functions called from both places cdclk and dpll so every platform
exporting a specific function won't be ideal.

so imo it would be good if we could organize this one starting here
already.

> 
> > 
> > Paolo, any opinions on this one?
> > 
> > > +
> > >  void intel_ddi_clock_get(struct intel_encoder *encoder,
> > >  			 struct intel_crtc_state *pipe_config)
> > >  {
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index 0cab667fff57..fe4650d6db03 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -1293,7 +1293,8 @@ bool intel_ddi_is_audio_enabled(struct
> > > drm_i915_private *dev_priv,
> > >  				 struct intel_crtc *intel_crtc);
> > >  void intel_ddi_get_config(struct intel_encoder *encoder,
> > >  			  struct intel_crtc_state *pipe_config);
> > > -
> > > +int intel_ddi_port_clock(struct drm_i915_private *dev_priv,
> > > +			 enum intel_dpll_id pll_id);
> > >  void intel_ddi_clock_get(struct intel_encoder *encoder,
> > >  			 struct intel_crtc_state *pipe_config);
> > >  void intel_ddi_set_vc_payload_alloc(const struct intel_crtc_state
> > > *crtc_state,
> > -- 
> > Mika Kahola - Intel OTC
> > 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply

* [PATCH tip/core/rcu 0/16] Documentation updates for v4.15
From: Paul E. McKenney @ 2017-10-04 21:20 UTC (permalink / raw)
  To: linux-kernel
  Cc: mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh,
	tglx, peterz, rostedt, dhowells, edumazet, fweisbec, oleg

Hello!

This series contains documentation updates, including some updates to
docbook header comments:

1.	Design documentation illustrating RCU's grace-period memory
	ordering guarantees.

2.	Add verbiage stating that long-running irq handlers can stall
	RCU grace periods.

3.	Add verbiage stating that slow systems can stall RCU grace periods.

4.	Update description of RCU CPU stall warning messages.

5.	Replace uses of "transitive" in memory-barriers.txt.

6.	Rework multicopy-atomicity section of memory-barriers.txt,
	courtesy of Alan Stern.

7.	Fix RCU's docbook options.

8.	Add parameters to rcupdate.h docbook comments.

9.	Remove extra docbook comment in rculist.h.

10.	Fix docbook comments for rcu_sync functions.

11.	Fix list and emphasis in rcupdate.h docbook comments.

12.	Flag code segment in rcu_pointer_handoff()'s docbook comment.

13.	Fix code display in rcu_pointer_handoff()'s docbook comment.

14.	Fix tree.c bulleted lists in docbook comments.

15.	Fix typo in pairing example in memory-barriers.txt, courtesy
	of Scott Tsai.

16.	Rewrite confusing statement about memory barriers in
	memory-barriers.txt, courtesy of Guilherme G. Piccoli.

							Thanx, Paul

------------------------------------------------------------------------

 Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Diagram.html           |    9 
 Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.html   |  707 +
 Documentation/RCU/Design/Memory-Ordering/TreeRCU-callback-invocation.svg |  486 
 Documentation/RCU/Design/Memory-Ordering/TreeRCU-callback-registry.svg   |  655 +
 Documentation/RCU/Design/Memory-Ordering/TreeRCU-dyntick.svg             |  700 +
 Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-cleanup.svg          | 1126 ++
 Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-fqs.svg              | 1309 ++
 Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-init-1.svg           |  656 +
 Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-init-2.svg           |  656 +
 Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-init-3.svg           |  632 +
 Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp.svg                  | 5135 ++++++++++
 Documentation/RCU/Design/Memory-Ordering/TreeRCU-hotplug.svg             |  775 +
 Documentation/RCU/Design/Memory-Ordering/TreeRCU-qs.svg                  | 1095 ++
 Documentation/RCU/Design/Memory-Ordering/rcu_node-lock.svg               |  229 
 Documentation/RCU/stallwarn.txt                                          |  200 
 Documentation/core-api/kernel-api.rst                                    |   14 
 Documentation/memory-barriers.txt                                        |  249 
 include/linux/rculist.h                                                  |    2 
 include/linux/rcupdate.h                                                 |   26 
 kernel/rcu/sync.c                                                        |    9 
 kernel/rcu/tree.c                                                        |   18 
 21 files changed, 14449 insertions(+), 239 deletions(-)

^ permalink raw reply

* Re: hacktoberfest
From: pedro rijo @ 2017-10-04 21:20 UTC (permalink / raw)
  To: Jeff King; +Cc: Git Users
In-Reply-To: <20170928211859.uw7dep6gypsifivy@sigill.intra.peff.net>

seems my last answer was blocked due to HTML :(

here's the answer: Seems a nice start yes. I've been on vacations, but
next week I will go trough the current issues and add the
hacktoberfest label to some issues if you agree.

I went through the open issues a few moments ago. Some were closed
(solved or not applicable anymore), and some got an hacktoberfest
label, hoping new contributors pop up. Feel free to have a look and
add new issues to the label, as well as remove some of those I thought
it could be a good fit. There are easy issue, and some not so easy
(not very hard, but a bit more work) probably.

Issues labeled:
https://github.com/git/git-scm.com/issues?q=is%3Aopen+is%3Aissue+label%3Ahacktoberfest

Thanks,
Pedro

2017-09-28 22:19 GMT+01:00 Jeff King <peff@peff.net>:
> On Wed, Sep 27, 2017 at 11:05:49PM +0100, pedro rijo wrote:
>
>> While the git repository itself is not hosted under GitHub, the Pro
>> Git book, git for Windows, and git-scm website (at least) projects
>> are, and could use this movement to get some more contributions, and
>> eventually more maintainers (at least git-scm website had some
>> maintainers problem some time ago).
>>
>> I've been helping on the git-scm repository (mostly filtering issues
>> and PRs), and I know there are still some issues which need to be
>> addressed. If the remaining maintainers agree, we could filter and
>> provide more instructions to some easy (or not so easy) issues, adding
>> the 'hacktoberfest' label and try to use this movement to solve some
>> problems
>
> I'd love it if more people wanted to contribute to the git-scm
> repository. I think one can probably find some low-hanging fruit by
> looking at the open issues list (though I'd be happy, too, if people
> with bug or feature suggestions opened new issues).
>
> Here are a couple small-to-moderate bugs that have been languishing:
>
>   https://github.com/git/git-scm.com/issues/701
>
>   https://github.com/git/git-scm.com/issues/987
>
>   https://github.com/git/git-scm.com/issues/994
>
> -Peff



-- 
Obrigado,

Pedro Rijo

^ permalink raw reply

* [PATCH 0/9] Bringing Asus TF300T support to mainline
From: Michał Mirosław @ 2017-10-04 21:25 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <cover.1500510157.git.mirq-linux@rere.qmqm.pl>

On Thu, Jul 20, 2017 at 02:29:22AM +0200, Micha? Miros?aw wrote:
> Here is a suprisingly small set of patches that enable Asus TF300T tablet
> to boot and have all cores available. TF300T is one of a consumer devices
> based on NVidia's Cardhu reference tablet.
> 
> This series is an arch-dependent part. TF parts were extracted from ASUS's
> GPL code dump.  The rest being driver code - a work in progress - is
> available in branch tf300t at:
> 
>         https://rere.qmqm.pl/git/linux

Just a quick note, that I've rebased the branch on v4.14-rc3 and added
some more patches on top. This includes updated defconfig and devicetree
with working eMMC and an attempt at making TF300T's dock hot-pluggable.

Best Regards,
Micha? Miros?aw

^ permalink raw reply

* Re: [PATCH 0/9] Bringing Asus TF300T support to mainline
From: Michał Mirosław @ 2017-10-04 21:25 UTC (permalink / raw)
  To: linux-tegra, linux-arm-kernel
In-Reply-To: <cover.1500510157.git.mirq-linux@rere.qmqm.pl>

On Thu, Jul 20, 2017 at 02:29:22AM +0200, Michał Mirosław wrote:
> Here is a suprisingly small set of patches that enable Asus TF300T tablet
> to boot and have all cores available. TF300T is one of a consumer devices
> based on NVidia's Cardhu reference tablet.
> 
> This series is an arch-dependent part. TF parts were extracted from ASUS's
> GPL code dump.  The rest being driver code - a work in progress - is
> available in branch tf300t at:
> 
>         https://rere.qmqm.pl/git/linux

Just a quick note, that I've rebased the branch on v4.14-rc3 and added
some more patches on top. This includes updated defconfig and devicetree
with working eMMC and an attempt at making TF300T's dock hot-pluggable.

Best Regards,
Michał Mirosław

^ permalink raw reply

* [PATCH 6/7] gpio: brcmstb: consolidate interrupt domains
From: Doug Berger @ 2017-10-04 21:24 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CADtm3G5v6_BHwanRYvCq1y-8Hdmn7gxX3zoVHx2c7cOFL-pj+Q@mail.gmail.com>

On 10/03/2017 08:03 PM, Gregory Fong wrote:
> Hi Doug,
> 
> On Fri, Sep 29, 2017 at 8:40 PM, Doug Berger <opendmb@gmail.com> wrote:
>> The GPIOLIB IRQ chip helpers were very appealing, but badly broke
>> the 1:1 mapping between a GPIO controller's device_node and its
>> interrupt domain.
> 
> Out of curiosity, what sort of problems have you seen from this?
> 

As you know, the BRCMSTB devices conceptually distinguish between an
always-on GPIO device and a regular GPIO device that each can have many
more than 32 General Purpose I/Os. The driver supports these by dividing
the GPIO across a number of banks each of which is implemented as a
separate gpiochip as an implementation convenience. The main issue is
that each gpiochip that uses the GPIOLIB IRQ chip helpers creates its
own irq domain even though they are associated with the same device and
device-tree node.

When another device-tree node references a GPIO device as its interrupt
parent, the irq_create_of_mapping() function looks for the irq domain of
the GPIO device and since all bank irq domains reference the same GPIO
device node it always resolves to the irq domain of the first bank
regardless of which bank the number of the GPIO should resolve. This
domain can only map hwirq numbers 0-31 so interrupts on GPIO above that
can't be mapped by the device-tree.

>>
>> This commit consolidates the per bank irq domains to a version
>> where we have one larger interrupt domain per GPIO controller
>> instance spanning multiple GPIO banks.
> 
> This works (and is reminiscent to my initially submitted
> implementation at [1]), but I think it might make sense to keep as-is
> (using the gpiolib irqchip helpers), and instead allocate an irqchip
> fwnode per bank and use to_of_node() to set it as the of_node for the
> gpiochip before calling gpiochip_irqchip_add().  OTOH, that capability
> might go away...
> 
> Linus, can you comment on the FIXME in gpiochip_irqchip_add_key() that
> says "get rid of this and use gpiochip->parent->of_node everywhere"?
> It seems like it would still be beneficial to be able to override the
> associated node for a gpiochip, since that's what's used for the
> irqdomain, but if that's going away, obviously we don't want to start
> using that now.
> 

Yes, this is effectively a reversion to an earlier implementation. I
produced an implementation based on the generic irqchip libraries, but
that was stripped from this submission when I discovered that no support
exists within the generic irqchip libraries for removal of domain
generic chips and we wanted to preserve the module support of this driver.

It is conceivable that the current GPIO device-tree nodes could be
broken down into separate devices per bank, but it is believed that this
would only confuse things for users of the device as the concept
diverges from the concept expressed in device documentation.

> Thanks,
> Gregory
> 
> [1] https://patchwork.kernel.org/patch/6347811/
> 

Thanks for the review,
    Doug

^ permalink raw reply

* Re: [PATCH 6/7] gpio: brcmstb: consolidate interrupt domains
From: Doug Berger @ 2017-10-04 21:24 UTC (permalink / raw)
  To: Gregory Fong
  Cc: Linus Walleij, Brian Norris, Florian Fainelli,
	bcm-kernel-feedback-list, linux-gpio,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <CADtm3G5v6_BHwanRYvCq1y-8Hdmn7gxX3zoVHx2c7cOFL-pj+Q@mail.gmail.com>

On 10/03/2017 08:03 PM, Gregory Fong wrote:
> Hi Doug,
> 
> On Fri, Sep 29, 2017 at 8:40 PM, Doug Berger <opendmb@gmail.com> wrote:
>> The GPIOLIB IRQ chip helpers were very appealing, but badly broke
>> the 1:1 mapping between a GPIO controller's device_node and its
>> interrupt domain.
> 
> Out of curiosity, what sort of problems have you seen from this?
> 

As you know, the BRCMSTB devices conceptually distinguish between an
always-on GPIO device and a regular GPIO device that each can have many
more than 32 General Purpose I/Os. The driver supports these by dividing
the GPIO across a number of banks each of which is implemented as a
separate gpiochip as an implementation convenience. The main issue is
that each gpiochip that uses the GPIOLIB IRQ chip helpers creates its
own irq domain even though they are associated with the same device and
device-tree node.

When another device-tree node references a GPIO device as its interrupt
parent, the irq_create_of_mapping() function looks for the irq domain of
the GPIO device and since all bank irq domains reference the same GPIO
device node it always resolves to the irq domain of the first bank
regardless of which bank the number of the GPIO should resolve. This
domain can only map hwirq numbers 0-31 so interrupts on GPIO above that
can't be mapped by the device-tree.

>>
>> This commit consolidates the per bank irq domains to a version
>> where we have one larger interrupt domain per GPIO controller
>> instance spanning multiple GPIO banks.
> 
> This works (and is reminiscent to my initially submitted
> implementation at [1]), but I think it might make sense to keep as-is
> (using the gpiolib irqchip helpers), and instead allocate an irqchip
> fwnode per bank and use to_of_node() to set it as the of_node for the
> gpiochip before calling gpiochip_irqchip_add().  OTOH, that capability
> might go away...
> 
> Linus, can you comment on the FIXME in gpiochip_irqchip_add_key() that
> says "get rid of this and use gpiochip->parent->of_node everywhere"?
> It seems like it would still be beneficial to be able to override the
> associated node for a gpiochip, since that's what's used for the
> irqdomain, but if that's going away, obviously we don't want to start
> using that now.
> 

Yes, this is effectively a reversion to an earlier implementation. I
produced an implementation based on the generic irqchip libraries, but
that was stripped from this submission when I discovered that no support
exists within the generic irqchip libraries for removal of domain
generic chips and we wanted to preserve the module support of this driver.

It is conceivable that the current GPIO device-tree nodes could be
broken down into separate devices per bank, but it is believed that this
would only confuse things for users of the device as the concept
diverges from the concept expressed in device documentation.

> Thanks,
> Gregory
> 
> [1] https://patchwork.kernel.org/patch/6347811/
> 

Thanks for the review,
    Doug

^ permalink raw reply

* RE: [PATCH v4 rdma-next 17/18] IB/core: Define 'ib' and 'roce' rdma_ah_attr types
From: Parav Pandit @ 2017-10-04 21:24 UTC (permalink / raw)
  To: Dasaratharaman Chandramouli, Doug Ledford; +Cc: linux-rdma
In-Reply-To: <1493491290-31621-18-git-send-email-dasaratharaman.chandramouli-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

> -----Original Message-----
> From: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:linux-rdma-
> owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of Dasaratharaman Chandramouli
> Sent: Saturday, April 29, 2017 1:41 PM
> To: Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Cc: linux-rdma <linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Subject: [PATCH v4 rdma-next 17/18] IB/core: Define 'ib' and 'roce'
> rdma_ah_attr types

> +/*Get AH type */
> +static inline enum rdma_ah_attr_type rdma_ah_find_type(struct ib_device
> *dev,
> +						       u32 port_num)
> +{
> +	if ((rdma_protocol_roce(dev, port_num)) ||
> +	    (rdma_protocol_iwarp(dev, port_num)))
> +		return RDMA_AH_ATTR_TYPE_ROCE;

Check for iWarp to define AH attribute type as RoCE appears error to me.
Taking quick look at i40iw and nes drivers appears to return -ENOSYS for i40iw_create_ah(), nes_create_ah.
Will you please submit a fix that avoids above iWarp check?

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply


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.