rt-linux mailing list and discussions

[Pintu Agarwal]

Hi,
I just want to know which is the right and active mailing list for
contributing and discussing about rt-linux and preempt-rt related
changes.

Thanks,
Pintu

[PATCH v2] mm/compaction: remove unused variable sysctl_compact_memory

[Pintu Kumar]

The sysctl_compact_memory is mostly unused in mm/compaction.c
It just acts as a place holder for sysctl to store .data.

But the .data itself is not needed here.
So we can get ride of this variable completely and make .data as NULL.
This will also eliminate the extern declaration from header file.
No functionality is broken or changed this way.

Signed-off-by: Pintu Kumar 
Signed-off-by: Pintu Agarwal 
---
v2: completely get rid of this variable and set .data to NULL
Suggested-by: Vlastimil Babka 

 include/linux/compaction.h | 1 -
 kernel/sysctl.c| 2 +-
 mm/compaction.c| 3 ---
 3 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/include/linux/compaction.h b/include/linux/compaction.h
index ed4070e..4221888 100644
--- a/include/linux/compaction.h
+++ b/include/linux/compaction.h
@@ -81,7 +81,6 @@ static inline unsigned long compact_gap(unsigned int order)
 }
 
 #ifdef CONFIG_COMPACTION
-extern int sysctl_compact_memory;
 extern unsigned int sysctl_compaction_proactiveness;
 extern int sysctl_compaction_handler(struct ctl_table *table, int write,
void *buffer, size_t *length, loff_t *ppos);
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index c9fbdd8..07ef240 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -2856,7 +2856,7 @@ static struct ctl_table vm_table[] = {
 #ifdef CONFIG_COMPACTION
{
.procname   = "compact_memory",
-   .data   = _compact_memory,
+   .data   = NULL,
.maxlen = sizeof(int),
.mode   = 0200,
.proc_handler   = sysctl_compaction_handler,
diff --git a/mm/compaction.c b/mm/compaction.c
index 190ccda..ede2886 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -2650,9 +2650,6 @@ static void compact_nodes(void)
compact_node(nid);
 }
 
-/* The written value is actually unused, all memory is compacted */
-int sysctl_compact_memory;
-
 /*
  * Tunable for proactive compaction. It determines how
  * aggressively the kernel should compact memory in the
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH] mm/compaction: remove unused variable sysctl_compact_memory

[pintu]

On 2021-03-03 22:39, Vlastimil Babka wrote:

On 3/2/21 6:56 PM, Pintu Kumar wrote:

The sysctl_compact_memory is mostly unsed in mm/compaction.c
It just acts as a place holder for sysctl.

Thus we can remove it from here and move the declaration directly
in kernel/sysctl.c itself.
This will also eliminate the extern declaration from header file.
No functionality is broken or changed this way.

Signed-off-by: Pintu Kumar 
Signed-off-by: Pintu Agarwal 


You should be able to remove the variable completely and set .data to 
NULL in
the corresponding entry. The sysctl_compaction_handler doesn't access 
it at all.


Then you could do the same with drop_caches. Currently
drop_caches_sysctl_handler currently writes to it, but that can be 
avoided using
a local variable - see how sysrq_sysctl_handler avoids the global 
variable and

its corresponding .data field is NULL.



Oh yes, thank you so much for the reference.
Yes I was looking to do something similar but didn't realize that is 
possible.

I will re-submit the new patch.

And yes, I will try to explore more on drop_caches part as well.

Thanks,
Pintu

Re: [PATCH] mm/compaction: remove unused variable sysctl_compact_memory

[pintu]

On 2021-03-03 01:48, Nitin Gupta wrote:

-Original Message-
From: pintu=codeaurora@mg.codeaurora.org
 On Behalf Of Pintu Kumar
Sent: Tuesday, March 2, 2021 9:56 AM
To: linux-kernel@vger.kernel.org; a...@linux-foundation.org; linux-
m...@kvack.org; linux-fsde...@vger.kernel.org; pi...@codeaurora.org;
iamjoonsoo@lge.com; sh_...@163.com; mateusznos...@gmail.com;
b...@redhat.com; Nitin Gupta ; vba...@suse.cz;
yzai...@google.com; keesc...@chromium.org; mcg...@kernel.org;
mgor...@techsingularity.net
Cc: pintu.p...@gmail.com
Subject: [PATCH] mm/compaction: remove unused variable
sysctl_compact_memory

External email: Use caution opening links or attachments


The sysctl_compact_memory is mostly unsed in mm/compaction.c It just 
acts

as a place holder for sysctl.

Thus we can remove it from here and move the declaration directly in
kernel/sysctl.c itself.
This will also eliminate the extern declaration from header file.



I prefer keeping the existing pattern of listing all compaction related 
tunables

together in compaction.h:

extern int sysctl_compact_memory;
extern unsigned int sysctl_compaction_proactiveness;
extern int sysctl_extfrag_threshold;
extern int sysctl_compact_unevictable_allowed;



Thanks Nitin for your review.
You mean, you just wanted to retain this extern declaration ?
Any real benefit of keeping this declaration if not used elsewhere ?




No functionality is broken or changed this way.

Signed-off-by: Pintu Kumar 
Signed-off-by: Pintu Agarwal 
---
 include/linux/compaction.h | 1 -
 kernel/sysctl.c| 1 +
 mm/compaction.c| 3 ---
 3 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/include/linux/compaction.h b/include/linux/compaction.h 
index

ed4070e..4221888 100644
--- a/include/linux/compaction.h
+++ b/include/linux/compaction.h
@@ -81,7 +81,6 @@ static inline unsigned long compact_gap(unsigned int
order)  }

 #ifdef CONFIG_COMPACTION
-extern int sysctl_compact_memory;
 extern unsigned int sysctl_compaction_proactiveness;  extern int
sysctl_compaction_handler(struct ctl_table *table, int write,
void *buffer, size_t *length, loff_t *ppos); 
diff --git

a/kernel/sysctl.c b/kernel/sysctl.c index c9fbdd8..66aff21 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -198,6 +198,7 @@ static int max_sched_tunable_scaling =
SCHED_TUNABLESCALING_END-1;  #ifdef CONFIG_COMPACTION  static int
min_extfrag_threshold;  static int max_extfrag_threshold = 1000;
+static int sysctl_compact_memory;
 #endif

 #endif /* CONFIG_SYSCTL */
diff --git a/mm/compaction.c b/mm/compaction.c index 190ccda..ede2886
100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -2650,9 +2650,6 @@ static void compact_nodes(void)
compact_node(nid);
 }

-/* The written value is actually unused, all memory is compacted */ 
-int

sysctl_compact_memory;
-



Please retain this comment for the tunable.


Sorry, I could not understand.
You mean to say just retain this last comment and only remove the 
variable ?

Again any real benefit you see in retaining this even if its not used?


Thanks,
Pintu

Re: [PATCH] mm: introduce clear all vm events counters

[pintu]

On 2021-03-02 21:26, Johannes Weiner wrote:

On Tue, Mar 02, 2021 at 04:00:34PM +0530, pi...@codeaurora.org wrote:

On 2021-03-01 20:41, Johannes Weiner wrote:
> On Mon, Mar 01, 2021 at 04:19:26PM +0530, Pintu Kumar wrote:
> > At times there is a need to regularly monitor vm counters while we
> > reproduce some issue, or it could be as simple as gathering some
> > system
> > statistics when we run some scenario and every time we like to start
> > from
> > beginning.
> > The current steps are:
> > Dump /proc/vmstat
> > Run some scenario
> > Dump /proc/vmstat again
> > Generate some data or graph
> > reboot and repeat again
>
> You can subtract the first vmstat dump from the second to get the
> event delta for the scenario run. That's what I do, and I'd assume
> most people are doing. Am I missing something?

Thanks so much for your comments.
Yes in most cases it works.

But I guess there are sometimes where we need to compare with fresh 
data

(just like reboot) at least for some of the counters.
Suppose we wanted to monitor pgalloc_normal and pgfree.


Hopefully these would already be balanced out pretty well before you
run a test, or there is a risk that whatever outstanding allocations
there are can cause a large number of frees during your test that
don't match up to your recorded allocation events. Resetting to zero
doesn't eliminate the risk of such background noise.


Or, suppose we want to monitor until the field becomes non-zero..
Or, how certain values are changing compared to fresh reboot.
Or, suppose we want to reset all counters after boot and start 
capturing

fresh stats.


Again, there simply is no mathematical difference between

reset events to 0
run test
look at events - 0

and

read events baseline
run test
look at events - baseline

Some of the counters could be growing too large and too fast. Will 
there be

chances of overflow ?
Then resetting using this could help without rebooting.


Overflows are just a fact of life on 32 bit systems. However, they can
also be trivially handled - you can always subtract a ulong start
state from a ulong end state and get a reliable delta of up to 2^32
events, whether the end state has overflowed or not.

The bottom line is that the benefit of this patch adds a minor
convenience for something that can already be done in userspace. But
the downside is that there would be one more possible source of noise
for kernel developers to consider when looking at a bug report. Plus
the extra code and user interface that need to be maintained.

I don't think we should merge this patch.


Okay no problem.Thank you so much for your review and feedback.
Yes I agree the benefits are minor but I thought might be useful for 
someone somewhere.

I worked on it and found it easy and convinient and thus proposed it.
If others feel not important I am okay to drop it.

Thanks once again to all who helped to review it.

[PATCH] mm/compaction: remove unused variable sysctl_compact_memory

[Pintu Kumar]

The sysctl_compact_memory is mostly unsed in mm/compaction.c
It just acts as a place holder for sysctl.

Thus we can remove it from here and move the declaration directly
in kernel/sysctl.c itself.
This will also eliminate the extern declaration from header file.
No functionality is broken or changed this way.

Signed-off-by: Pintu Kumar 
Signed-off-by: Pintu Agarwal 
---
 include/linux/compaction.h | 1 -
 kernel/sysctl.c| 1 +
 mm/compaction.c| 3 ---
 3 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/include/linux/compaction.h b/include/linux/compaction.h
index ed4070e..4221888 100644
--- a/include/linux/compaction.h
+++ b/include/linux/compaction.h
@@ -81,7 +81,6 @@ static inline unsigned long compact_gap(unsigned int order)
 }
 
 #ifdef CONFIG_COMPACTION
-extern int sysctl_compact_memory;
 extern unsigned int sysctl_compaction_proactiveness;
 extern int sysctl_compaction_handler(struct ctl_table *table, int write,
void *buffer, size_t *length, loff_t *ppos);
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index c9fbdd8..66aff21 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -198,6 +198,7 @@ static int max_sched_tunable_scaling = 
SCHED_TUNABLESCALING_END-1;
 #ifdef CONFIG_COMPACTION
 static int min_extfrag_threshold;
 static int max_extfrag_threshold = 1000;
+static int sysctl_compact_memory;
 #endif
 
 #endif /* CONFIG_SYSCTL */
diff --git a/mm/compaction.c b/mm/compaction.c
index 190ccda..ede2886 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -2650,9 +2650,6 @@ static void compact_nodes(void)
compact_node(nid);
 }
 
-/* The written value is actually unused, all memory is compacted */
-int sysctl_compact_memory;
-
 /*
  * Tunable for proactive compaction. It determines how
  * aggressively the kernel should compact memory in the
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH] mm: introduce clear all vm events counters

[pintu]

On 2021-03-01 20:41, Johannes Weiner wrote:

On Mon, Mar 01, 2021 at 04:19:26PM +0530, Pintu Kumar wrote:

At times there is a need to regularly monitor vm counters while we
reproduce some issue, or it could be as simple as gathering some 
system
statistics when we run some scenario and every time we like to start 
from

beginning.
The current steps are:
Dump /proc/vmstat
Run some scenario
Dump /proc/vmstat again
Generate some data or graph
reboot and repeat again


You can subtract the first vmstat dump from the second to get the
event delta for the scenario run. That's what I do, and I'd assume
most people are doing. Am I missing something?


Thanks so much for your comments.
Yes in most cases it works.

But I guess there are sometimes where we need to compare with fresh data 
(just like reboot) at least for some of the counters.

Suppose we wanted to monitor pgalloc_normal and pgfree.
Or, suppose we want to monitor until the field becomes non-zero..
Or, how certain values are changing compared to fresh reboot.
Or, suppose we want to reset all counters after boot and start capturing 
fresh stats.


Some of the counters could be growing too large and too fast. Will there 
be chances of overflow ?

Then resetting using this could help without rebooting.

Suppose system came back from hibernation, and we want to reset all 
counters again (to capture fresh data) ?


Here I am sharing one output (from qemu-arm32 with 256MB RAM) just to 
indicate what could be changed:

Scenario: Generate OOM kill case and check oom_kill counter

BEFORE  AFTER   proc/vmstat
--  --  ---
49991   49916   nr_free_pages
44674481nr_zone_inactive_anon
68  68  nr_zone_active_anon
31893067nr_zone_inactive_file
223 444 nr_zone_active_file
0   0   nr_zone_unevictable
122 136 nr_zone_write_pending
0   0   nr_mlock
139 139 nr_page_table_pages
0   0   nr_bounce
0   0   nr_zspages
40324032nr_free_cma
44674481nr_inactive_anon
68  68  nr_active_anon
31893067nr_inactive_file
223 444 nr_active_file
0   0   nr_unevictable
11771178nr_slab_reclaimable
18891889nr_slab_unreclaimable
0   0   nr_isolated_anon
0   0   nr_isolated_file
176 163 workingset_nodes
0   0   workingset_refault_anon
32953369workingset_refault_file
0   0   workingset_activate_anon
4   4   workingset_activate_file
0   0   workingset_restore_anon
4   4   workingset_restore_file
0   0   workingset_nodereclaim
44364436nr_anon_pages
26362678nr_mapped
35593645nr_file_pages
122 136 nr_dirty
0   0   nr_writeback
0   0   nr_writeback_temp
126 126 nr_shmem
0   0   nr_shmem_hugepages
0   0   nr_shmem_pmdmapped
0   0   nr_file_hugepages
0   0   nr_file_pmdmapped
0   0   nr_anon_transparent_hugepages
1   1   nr_vmscan_write
1   1   nr_vmscan_immediate_reclaim
10241038nr_dirtied
902 902 nr_written
0   0   nr_kernel_misc_reclaimable
0   0   nr_foll_pin_acquired
0   0   nr_foll_pin_released
616 616 nr_kernel_stack
10529   10533   nr_dirty_threshold
52585260nr_dirty_background_threshold
50714   256 pgpgin
393216  pgpgout
0   0   pswpin
0   0   pswpout
86828   122 pgalloc_normal
0   0   pgalloc_movable
0   0   allocstall_normal
22  0   allocstall_movable
0   0   pgskip_normal
0   0   pgskip_movable
139594  34  pgfree
4998155 pgactivate
57380   pgdeactivate
0   0   pglazyfree
82113   122 pgfault
374 2   pgmajfault
0   0   pglazyfreed
76950   pgrefill
271820  pgreuse
92610   pgsteal_kswapd
173 0   pgsteal_direct
12627   0   pgscan_kswapd
283 0   pgscan_direct
2   0   pgscan_direct_throttle
0   0   pgscan_anon
12910   0   pgscan_file
0   0   pgsteal_anon
94340   pgsteal_file
0   0   pginodesteal
70080   slabs_scanned
109 0   kswapd_inodesteal
16  0   kswapd_low_wmark_hit_quickly
24  0   kswapd_high_wmark_hit_quickly
43  0   pageoutrun
1   0   pgrotated
0   0   drop_pagecache
0   0   drop_slab
1   0   oom_kill
12100   pgmigrate_success
0   0   pgmigrate_fail
0   0   thp_migration_success
0   0   thp_migration_fail
0   0   thp_migration_split
15090   compact_migrate_scanned
90150   compact_free_scanned
39110   compact_isolated
0   0   compact_stall
0   0   compact_fail
0   0   compact_success
3   0   compact_daemon_wake
15090   compact_daemon_migrate_scanned
90150   compact_daemon_free_scanned
0   0

Re: [PATCH] mm: introduce clear all vm events counters

[pintu]

On 2021-03-01 17:43, Matthew Wilcox wrote:

On Mon, Mar 01, 2021 at 04:19:26PM +0530, Pintu Kumar wrote:

+EXPORT_SYMBOL_GPL(clear_all_vm_events);


What module uses this function?


oh sorry, I will remove the EXPORT
Thanks for the review.


Regards,
Pintu

[PATCH] mm: introduce clear all vm events counters

[Pintu Kumar]

At times there is a need to regularly monitor vm counters while we
reproduce some issue, or it could be as simple as gathering some system
statistics when we run some scenario and every time we like to start from
beginning.
The current steps are:
Dump /proc/vmstat
Run some scenario
Dump /proc/vmstat again
Generate some data or graph
reboot and repeat again

So, each time we wanted to capture fresh data a reboot is required.

Thus, in this patch I introduce a way to clear/reset all vm counters to 0
without rebooting the system.
With this patch the steps can be:
Dump /proc/vmstat
Run some scenario
Dump /proc/vmstat again
Generate some data or graph
Do: echo 1 > /proc/sys/vm/clear_all_vm_events
Then repeat again

Thus, when 1 is written to this file, it resets all the vm counters present
under /proc/vmstat to its default value or zero.
The next time when you read /proc/vmstat, each node is filled with default
or current value.

There could be few other use cases where this can be useful.

Signed-off-by: Pintu Kumar 
Signed-off-by: Pintu Agarwal 
---
 Documentation/admin-guide/sysctl/vm.rst |  8 
 include/linux/vmstat.h  |  7 +++
 kernel/sysctl.c |  9 +
 mm/vmstat.c | 26 ++
 4 files changed, 50 insertions(+)

diff --git a/Documentation/admin-guide/sysctl/vm.rst 
b/Documentation/admin-guide/sysctl/vm.rst
index e35a3f2..54382ab 100644
--- a/Documentation/admin-guide/sysctl/vm.rst
+++ b/Documentation/admin-guide/sysctl/vm.rst
@@ -26,6 +26,7 @@ Currently, these files are in /proc/sys/vm:
 
 - admin_reserve_kbytes
 - block_dump
+- clear_all_vm_events
 - compact_memory
 - compaction_proactiveness
 - compact_unevictable_allowed
@@ -112,6 +113,13 @@ block_dump
 block_dump enables block I/O debugging when set to a nonzero value. More
 information on block I/O debugging is in 
Documentation/admin-guide/laptops/laptop-mode.rst.
 
+clear_all_vm_events
+===
+
+When 1 is written to this file, it resets all the vm counters present under
+/proc/vmstat to its default value or zeros.
+The next time when you read /proc/vmstat, each node is filled with default or
+current value.
 
 compact_memory
 ==
diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
index 773135f..8ab9be5 100644
--- a/include/linux/vmstat.h
+++ b/include/linux/vmstat.h
@@ -11,6 +11,8 @@
 #include 
 
 extern int sysctl_stat_interval;
+extern int sysctl_clearvmevents_handler(struct ctl_table *table, int write,
+   void __user *buffer, size_t *length, loff_t *ppos);
 
 #ifdef CONFIG_NUMA
 #define ENABLE_NUMA_STAT   1
@@ -83,6 +85,8 @@ static inline void count_vm_events(enum vm_event_item item, 
long delta)
 
 extern void all_vm_events(unsigned long *);
 
+extern void clear_all_vm_events(void);
+
 extern void vm_events_fold_cpu(int cpu);
 
 #else
@@ -103,6 +107,9 @@ static inline void __count_vm_events(enum vm_event_item 
item, long delta)
 static inline void all_vm_events(unsigned long *ret)
 {
 }
+static inline void clear_all_vm_events(void)
+{
+}
 static inline void vm_events_fold_cpu(int cpu)
 {
 }
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index c9fbdd8..25299a4 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -200,6 +200,8 @@ static int min_extfrag_threshold;
 static int max_extfrag_threshold = 1000;
 #endif
 
+static int sysctl_clear_vm_events;
+
 #endif /* CONFIG_SYSCTL */
 
 #if defined(CONFIG_BPF_SYSCALL) && defined(CONFIG_SYSCTL)
@@ -2891,6 +2893,13 @@ static struct ctl_table vm_table[] = {
 
 #endif /* CONFIG_COMPACTION */
{
+   .procname   = "clear_all_vm_events",
+   .data   = _clear_vm_events,
+   .maxlen = sizeof(int),
+   .mode   = 0200,
+   .proc_handler   = sysctl_clearvmevents_handler,
+   },
+   {
.procname   = "min_free_kbytes",
.data   = _free_kbytes,
.maxlen = sizeof(min_free_kbytes),
diff --git a/mm/vmstat.c b/mm/vmstat.c
index f894216..26b8f81 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -136,6 +136,32 @@ void all_vm_events(unsigned long *ret)
 }
 EXPORT_SYMBOL_GPL(all_vm_events);
 
+void clear_all_vm_events(void)
+{
+   int cpu;
+
+   for_each_online_cpu(cpu) {
+   struct vm_event_state *this = _cpu(vm_event_states, cpu);
+   int sz = NR_VM_EVENT_ITEMS * sizeof(unsigned long);
+
+   memset(this->event, 0, sz);
+   }
+}
+EXPORT_SYMBOL_GPL(clear_all_vm_events);
+
+/*
+ * This is the node to reset all vm events in /proc/vmstat
+ * via /proc/sys/vm/clear_all_vm_events
+ */
+int sysctl_clearvmevents_handler(struct ctl_table *table, int write,
+   void __user *buffer, size_t *length, loff_t *ppos)
+{
+   if (write)
+   clear_all_vm_events();
+
+   return 0;
+}
+
 /*
  * Fold the foreign cpu events into our o

Re: [PATCH] mm: cma: support sysfs

[Pintu Agarwal]

On Sat, 6 Feb 2021 at 04:17, Minchan Kim  wrote:
>
> On Fri, Feb 05, 2021 at 01:58:06PM -0800, John Hubbard wrote:
> > On 2/5/21 1:52 PM, Suren Baghdasaryan wrote:
> > > > > > I takes your suggestion something like this.
> > > > > >
> > > > > > [alloc_range] could be order or range by interval
> > > > > >
> > > > > > /sys/kernel/mm/cma/cma-A/[alloc_range]/success
> > > > > > /sys/kernel/mm/cma/cma-A/[alloc_range]/fail
> > > > > > ..
> > > > > > ..
> > > > > > /sys/kernel/mm/cma/cma-Z/[alloc_range]/success
> > > > > > /sys/kernel/mm/cma/cma-Z/[alloc_range]/fail
> > >
> > > The interface above seems to me the most useful actually, if by
> > > [alloc_range] you mean the different allocation orders. This would
> > > cover Minchan's per-CMA failure tracking and would also allow us to
> > > understand what kind of allocations are failing and therefore if the
> > > problem is caused by pinning/fragmentation or by over-utilization.
> > >
> >
> > I agree. That seems about right, now that we've established that
> > cma areas are a must-have.
>
> Okay, now we agreed the dirction right now so let me do that in next
> version. If you don't see it's reasonable, let me know.
>
> * I will drop the number of CMA *page* allocation attemtps/failures to
> make simple start
> * I will keep CMA allocation attemtps/failures
> * They will be under /sys/kernel/mm/cma/cma-XX/success,fail
> * It will turn on CONFIG_CMA && CONFIG_SYSFS
>
> Orthognal work(diffrent patchset)
>
> * adding global CMA alloc/fail into vmstat
> * adding alloc_range success/failure under CONFIG_CMA_ALLOC_TRACKING
>   whatever configuration or just by default if everyone agree
>

> # cat meminfo | grep -i cma
> CmaTotal:1048576 kB
> CmaFree: 1046872 kB

This CMA info was added by me way back in 2014.
At that time I even thought about adding this cma alloc/fail counter in vmstat.
That time I also had an internal patch about it but later dropped
(never released to mainline).
If required I can re-work again on this part.

And I have few more points to add here.
1) In the past I have faced this cma allocation failure (which could
be common in small embedded devices).
Earlier it was even difficult to figure if cma failure actually happened.
Thus I added this simple patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.11-rc6=5984af1082f3b115082178ed88c47033d43b924d

2) IMO just reporting CMA alloc/fail may not be enough (at times). The
main point is for which client/dev is this failure happening ?
Sometimes just tuning the size or fixing the alignment can resolve the
failure if we know the client. For global CMA it will be just NULL
(dev).

3) IMO having 2 options SYSFS and DEBUGFS may confuse the
developer/user (personal experience). So are we going to remove the
DEBUGFS or merge it ?

4) Sometimes CMA (or DMA) allocation failure can happen even very
early in boot time itself. At that time these are anyways not useful.
Some system may not proceed if CMA/DMA allocation is failing (again
personal experience).
==> Anyways this is altogether is different case...

5) The default max CMA areas are defined to be 7 but user can
configure it to any number, may be 20 or 50 (???)

6) Thus I would like to propose another thing here.
Just like we have /proc/vmallocinfo, /proc/slabinfo, etc., we can also
have: /proc/cmainfo
Here in /proc/cmaminfo we can capute more detailed information:
Global CMA Data: Alloc/Free
Client specific data: name, size, success, fail, flags, align, etc
(just a random example).
==> This can dynamically grow as large as possible
==> It can also be enabled/disabled based on CMA config itself (no
additional config required)

Any feedback on point (6) specifically ?


Thanks,
Pintu

Re: [BUG]: Kernel 4.9: Kernel crash at fs/sysfs/file.c : sysfs_kf_seq_show

[Pintu Agarwal]

On Wed, 13 Jan 2021 at 17:57, Greg Kroah-Hartman
 wrote:

>
> And, if you look close at the above links, you will see where the error
> is, and what the out-of-tree code needs to to do be fixed up properly.
> An exercise for that is left for the vendor :)

Seems like I have fixed the issue myself. There is problem in the
probe method itself.
Further debugging in progress.

Thanks for your inputs.

Regards,
Pintu

Re: [BUG]: Kernel 4.9: Kernel crash at fs/sysfs/file.c : sysfs_kf_seq_show

[Pintu Agarwal]

On Tue, 12 Jan 2021 at 17:39, Greg Kroah-Hartman
 wrote:
>
> On Tue, Jan 12, 2021 at 05:31:54PM +0530, Pintu Agarwal wrote:
> > Hi,
> >
> > I am using Kernel: 4.9.217 for one of the ARM32 boards for Qualcomm SOC.
> > https://github.com/android-linux-stable/msm-4.9
> >
> > But I think this is a general bug applicable to :Kernel 4.9 under
> > fs/sysfs/file.c
> > So, I wanted to quickly check here if others are familiar with this
> > issue and if it is fixed already.
> > Note, this issue does not occur in 4.14 Kernel.
> >
> > When I execute below command, the Kernel is crashing.
> > I tried to add few debug prints to find more details. I see that the
> > ops->show pointer is not valid (seems corrupted).
> > So I wanted to understand how this can happen only for this particular node.
> > Other sysfs entries are working fine.
> >

I see that this issue was reported earlier as well by others.
https://syzkaller.appspot.com/bug?id=2ec2a9da5c711df3d3d12071bac487b96e75e103
https://gitlab.freedesktop.org/drm/amd/-/issues/413
https://bugzilla.redhat.com/show_bug.cgi?id=1615070

So it seems to be common issue and thus I wanted to check here if its similar.

Thanks,
Pintu

[BUG]: Kernel 4.9: Kernel crash at fs/sysfs/file.c : sysfs_kf_seq_show

[Pintu Agarwal]

 d8a29ddc
[  141.252919] 9d80: d8a29dd8 d8a29de8 d9f69000 d9ffd940 d9ffe800
c03aaef0  d8a29e00
[  141.261077] 9da0: e000  0010 d8a29ec0 d9ffe800
c021f8cc d8a29de0 
[  141.269237] 9dc0: 0010 c024cb90  c1ecb000 0001
d9ffd940 d9ffd940 
[  141.277396] 9de0:   0008  0100
d9f69000  
[  141.285556] 9e00: d9fb1000 1000 c1b31000 1000 d9f3a000
1000 d9fb 1000
[  141.293716] 9e20: d9f48000 1000 d9fbe000 1000 d9fb2000
1000 d9f5a000 1000
[  141.301877] 9e40: d9f49000 1000 d9f38000 1000 d9f39000
1000 d9f2e000 1000
[  141.310037] 9e60: d9f2f000 1000 d9f28000 1000 d9f29000
1000 d9f0a000 1000
[  141.318195] 9e80: d8a29ec0 d8a29ef0 d9f69000  d9ffe800
0100  c024d438
[  141.326355] 9ea0:  c024c8cc  c034accc 
 0002 c19c1c00
[  141.334515] 9ec0:   c1055150 d9ffe800 d8a29f40
  
[  141.342674] 9ee0: c19c1c00 7fff  c024ca38 0100
0100  c19c1c00
[  141.350834] 9f00:   d8a29f48  
  c19c1c00
[  141.358994] 9f20: d9ffe800  0100 c021fd08 0100
 d9ffe800 c1f9a000
[  141.367154] 9f40:     0020
  0100
[  141.375313] 9f60: 00ef  d8a28000 00ef be855bb4
c0220688 7fff 
[  141.383473] 9f80: 0100  0100 0100 
0100 00ef c0107a84
[  141.391633] 9fa0: d8a28000 c01078c0 0100  0001
0003  0100
[  141.399793] 9fc0: 0100  0100 00ef 0001
0001  be855bb4
[  141.407952] 9fe0: 7f696ad4 be855ba4 7f5c82fd b6e87358 600f0030
0001  
[  141.416126] [] (sysfs_kf_seq_show) from []
(seq_read+0x264/0x488)
[  141.424276] [] (seq_read) from []
(do_readv_writev+0x2a0/0x2ec)
[  141.432085] [] (do_readv_writev) from []
(vfs_readv+0x44/0x4c)
[  141.439550] [] (vfs_readv) from []
(default_file_splice_read+0x140/0x260)
[  141.447191] [] (default_file_splice_read) from
[] (splice_direct_to_actor+0xe4/0x1c0)
[  141.455785] [] (splice_direct_to_actor) from []
(do_splice_direct+0x90/0xa8)
[  141.465332] [] (do_splice_direct) from []
(do_sendfile+0x1b8/0x2d8)
[  141.474185] [] (do_sendfile) from []
(SyS_sendfile64+0xb0/0x13c)
[  141.481915] [] (SyS_sendfile64) from []
(ret_fast_syscall+0x0/0x28)
[  141.489898] Code: db7a4418 41ed0011 4fd7  (0003)
[  141.497619] ---[ end trace 1ad2096094348e6a ]---
[  141.503906] Kernel panic - not syncing: Fatal exception

--
Corresponding code is here:
https://github.com/android-linux-stable/msm-4.9/blob/kernel.lnx.4.9.r11-rel/fs/sysfs/file.c

If anybody is familiar with this issue please let us know.


Thanks,
Pintu

Re: [PATCH] mm/util.c: Add error logs for commitment overflow

[pintu]

On 2020-10-05 12:50, Michal Hocko wrote:

On Fri 02-10-20 21:53:37, pi...@codeaurora.org wrote:

On 2020-10-02 17:47, Michal Hocko wrote:

> > __vm_enough_memory: commitment overflow: ppid:150, pid:164,
> > pages:62451
> > fork failed[count:0]: Cannot allocate memory
>
> While I understand that fork failing due to overrcomit heuristic is non
> intuitive and I have seen people scratching heads due to this in the
> past I am not convinced this is a right approach to tackle the problem.

Dear Michal,
First, thank you so much for your review and comments.
I totally agree with you.

> First off, referencing pids is not really going to help much if process
> is short lived.

Yes, I agree with you.
But I think this is most important mainly for short lived processes 
itself.
Because, when this situation occurs, no one knows who could be the 
culprit.


Pid will not tell you much for those processes, right?

However, user keeps dumping "ps" or "top" in background to reproduce 
once

again.


I do not think this would be an effective way to catch the problem.
Especially with _once reporting. My experience with these reports is
that a reporter notices a malfunctioning (usually more complex)
workload. In some cases ENOMEM from fork is reported into the log by 
the

userspace.

For others it is strace -f that tells us that fork is failing and a
test with OVERCOMMIT_ALWAYS usually confirms the theory that this is
the culprit. But a rule of thumb is that it is almost always overcommit
to blame. Why? An undocumented secret is that ENOMEM resulting from an
actual memory allocation in the fork/clone path is close to impossible
because kernel does all it can to satisfy them (an even invokes OOM
killer). There are exceptions (e.g. like high order allocation) but
those should be very rare in that path.

At this time, we can easily match the pid, process-name (at least in 
most

cases).


Maybe our definitions of short lived processes differ but in my book
those are pretty hard to catch in flight.


> Secondly, __vm_enough_memory is about any address space
> allocation. Why would you be interested in parent when doing mmap?
>

Yes agree, we can remove ppid from here.
I thought it might be useful at least in case of fork (or short lived
process).


I suspect you have missed my point here. Let me clarify a bit more.
__vm_enough_memory is called from much more places than fork.
Essentially any mmap, brk etc are going though this. This is where
parent pid certainly doesn't make any sense. In fork this is a 
different

case because your forked process pid on its own doesn't make much sense
as it is going to die very quickly anyway. This is when parent is 
likely

a more important information.

That being said the content really depends on the specific path and 
that

suggestes that you are trying to log at a wrong layer.

Another question is whether we really need a logging done by the 
kernel.
Ratelimiting would be tricky to get right and we do not want to allow 
an

easy way to swamp logs either.
As already mentioned ENOMEM usually means overcommit failure. Maybe we
want to be more explicit this in the man page?



Thank you so much for your feedback.
First of all I am sorry for my delayed response.

As I understand, the conclusion here is that:
a) The pr_err_once is not helpful and neither pr_err_ratelimited ?
Even with this below logs:
+ pr_err_ratelimited("vm memory overflow: pid:%d, name: %s, 
pages:%ld\n",

+ current->pid, current->comm, pages);

b) This can be invoked from many places so we are adding the logging at 
wrong layer?

If so, any other better places which can be explored?

c) Adding logging at kernel layer is not the right approach to tackle 
this problem ?


d) Another thing we can do is, update the man page with more detailed 
information about this commitment overflow ?


e) May be returning ENOMEM (Cannot allocate memory) from VM path is 
slightly misleading for user space folks even though there are enough 
memory?
=> Either we can introduce ENOVMEM (Cannot create virtual memory 
mapping)
=> Or, update the documentation with approach to further debug this 
issue?


If there are any more suggestions to easily catch this issue please let 
us know, we can explore further.



Thanks,
Pintu

Re: [PATCH] mm/util.c: Add error logs for commitment overflow

[pintu]

On 2020-10-02 17:47, Michal Hocko wrote:

__vm_enough_memory: commitment overflow: ppid:150, pid:164, 
pages:62451

fork failed[count:0]: Cannot allocate memory


While I understand that fork failing due to overrcomit heuristic is non
intuitive and I have seen people scratching heads due to this in the
past I am not convinced this is a right approach to tackle the problem.


Dear Michal,
First, thank you so much for your review and comments.
I totally agree with you.


First off, referencing pids is not really going to help much if process
is short lived.


Yes, I agree with you.
But I think this is most important mainly for short lived processes 
itself.
Because, when this situation occurs, no one knows who could be the 
culprit.
However, user keeps dumping "ps" or "top" in background to reproduce 
once again.
At this time, we can easily match the pid, process-name (at least in 
most cases).



Secondly, __vm_enough_memory is about any address space
allocation. Why would you be interested in parent when doing mmap?



Yes agree, we can remove ppid from here.
I thought it might be useful at least in case of fork (or short lived 
process).



Last but not least _once is questionable as well. The first instance
might happen early during the system lifetime and you will not learn
about future failures so the overall point of debuggability is 
seriously

inhibited.

Maybe what you want is to report higher up the call chain (fork?) and
have it ratelimited rather than _once? Or maybe just try to live with
the confusing situation?



Okay agree. I can change to pr_err_ratelimited.
In-fact, initially I thought to use ratelimited itself but then I 
thought

just once also should be fine at least.


Thanks,
Pintu

Re: [PATCH] mm/util.c: Add error logs for commitment overflow

[pintu]

On 2020-10-02 17:41, Matthew Wilcox wrote:



I don't think the __func__ is particularly useful information.  I would
also expect the name of the process to be more interesting than the 
PID.

And why is the ppid useful?



Dear Matthew, First, thank you so much for your review and comments.
I totally agree with you.
Yes, initially I included process-name but later removed it to shrink 
some lines.
I thought just pid should be enough to figure out the culprit process 
from dumps.

Okay, I agree __func__ can also be removed.
ppid, I thought might be useful, so I included it. Okay I will remove 
that too.



Wouldn't this message be more useful?

fork: Would overcommit system (pid:162 name:./consume-and-fork.out)



Okay, yes I think this should be sufficient.
But I think printing pages also should be good to indicate the users to 
lack

information about this commitment.


ie put it in dup_mmap() and use current->comm


Sorry, this part about dup_mmap(), I could not understand.


Thanks,
Pintu

[PATCH] mm/util.c: Add error logs for commitment overflow

[Pintu Kumar]

The headless embedded devices often come with very limited amount
of RAM such as: 256MB or even lesser.
These types of system often rely on command line interface which can
execute system commands in the background using the fork/exec combination.
There could be even many child tasks invoked internally to handle multiple
requests.
In this scenario, if the parent task keeps committing large amount of
memory, there are chances that this commitment can easily overflow the
total RAM available in the system. Now if the parent process invokes fork
or system commands (using system() call) and the commitment ratio is at
50%, the request fails with the following, even though there are large
amount of free memory available in the system:
fork failed: Cannot allocate memory

If there are too many 3rd party tasks calling fork, it becomes difficult to
identify exactly which parent process is overcommitting memory.
Since, free memory is also available, this "Cannot allocate memory" from
fork creates confusion to application developer.

Thus, I found that this simple print message (even once) is helping in
quickly identifying the culprit.

This is the output we can see on a 256MB system and with a simple malloc
and fork program.

[root@ ~]# cat /proc/meminfo
MemTotal: 249520 kB   ==> 243MB
MemFree:  179100 kB

PPIDPID USERRSS VSZ STATARGS
 150164 root1440250580  S   ./consume-and-fork.out 243

__vm_enough_memory: commitment overflow: ppid:150, pid:164, pages:62451
fork failed[count:0]: Cannot allocate memory

Signed-off-by: Pintu Kumar 
---
 mm/util.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/util.c b/mm/util.c
index 5ef378a..9431ce7a 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -895,6 +895,9 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, 
int cap_sys_admin)
 error:
vm_unacct_memory(pages);
 
+   pr_err_once("%s: commitment overflow: ppid:%d, pid:%d, pages:%ld\n",
+   __func__, current->parent->pid, current->pid, pages);
+
return -ENOMEM;
 }
 
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: KASLR support on ARM with Kernel 4.9 and 4.14

[Pintu Agarwal]

On Tue, 29 Sep 2020 at 01:20, Kees Cook  wrote:

> Note that I still can't explain what you're seeing. /proc/kallsyms
> shouldn't be affected by these patches -- I would expect it to either
> report the true value or 00s.
>
> > I will disable kptr_restrict and check or, I will enable
> > CONFIG_DEBUG_CONSOLE_UNHASHED_POINTERS and check.
>
> I would start with kptr_restrict=0 and see if that changes the contents
> of /proc/kallsyms. If it does, then it is the hashing. If it doesn't,
> well, we're back to square one. :)

Actually in that board, the kptr_restrict=0 already in both case: 4.9
and 4.14 Kernel boards.
In another board with 4.14 and kptr_restrict=2, I see that the
addresses are 00 always.

I further checked that when I enable this config:
CONFIG_DEBUG_CONSOLE_UNHASHED_POINTERS,
then the addresses are remaining the same in every boot.
But this particular config is not present in 4.9 Kernel.
So, I think it is controlled using this config.

--
Pintu

Re: KASLR support on ARM with Kernel 4.9 and 4.14

[Pintu Agarwal]

On Mon, 28 Sep 2020 at 19:15, Pintu Agarwal  wrote:
>
> On Sat, 26 Sep 2020 at 22:10, Kees Cook  wrote:
>
> > > >> I wonder if this is an Android Common kernel?
> > > It uses the below kernel for 4.14:
> > > https://gitlab.com/quicla/kernel/msm-4.14/-/tree/LE.UM.3.4.2.r1.5  (or
> > > similar branch).
> >
> > Okay, so yes. And this appears to have the hashing of %p backported. I
> > cannot, however, explain why it's showing hashed pointers instead of
> > just NULL, though.
> >
> > It might be related to these commits but they're not in that kernel:
> > 3e5903eb9cff ("vsprintf: Prevent crash when dereferencing invalid pointers")
> > 7bd57fbc4a4d ("vsprintf: don't obfuscate NULL and error pointers")
> >
> > > ==> The case where symbol addresses are changing.
> > >
> > > kptr_restrict is set to 2 by default:
> > > / # cat /proc/sys/kernel/kptr_restrict
> > > 2
> > >
> > > Basically, the goal is:
> > > * To understand how addresses are changing in 4.14 Kernel (without
> > > KASLR support)?
> > > * Is it possible to support the same in 4.9 Kernel ?
> >
> > Try setting kptr_restrict to 0 and see if the symbol addresses change? I
> > suspect Ard is correct: there's no KASLR here, just hashed pointers
> > behaving weird on an old non-stock kernel. :)
> >
>
> Okay. Thank you so much for your comments and suggestions.
> You mean to say, setting kptr_restrict to 0 may avoid changing symbol
> addresses in 4.14 ?
> And, sorry, I could not understand the thing about this "hashed pointers".
> How can I check this behavior in source code to understand better?
> Is it possible to give some reference ?
> I wanted to disable this hash pointer on 4.14 kernel and check the behavior.
> Also if possible, we would like to make this similar change on 4.9
> kernel as well.
>

Okay, I found these changes in 4.14 kernel:
https://gitlab.com/quicla/kernel/msm-4.14/-/commit/e63732dbfe017aa0dbabac9d096b5fde8afbd395

Are we talking about this?
I cound not find this in 4.9 kernel.

I will disable kptr_restrict and check or, I will enable
CONFIG_DEBUG_CONSOLE_UNHASHED_POINTERS and check.


Thanks,
Pintu

Re: KASLR support on ARM with Kernel 4.9 and 4.14

[Pintu Agarwal]

On Sat, 26 Sep 2020 at 22:10, Kees Cook  wrote:

> > >> I wonder if this is an Android Common kernel?
> > It uses the below kernel for 4.14:
> > https://gitlab.com/quicla/kernel/msm-4.14/-/tree/LE.UM.3.4.2.r1.5  (or
> > similar branch).
>
> Okay, so yes. And this appears to have the hashing of %p backported. I
> cannot, however, explain why it's showing hashed pointers instead of
> just NULL, though.
>
> It might be related to these commits but they're not in that kernel:
> 3e5903eb9cff ("vsprintf: Prevent crash when dereferencing invalid pointers")
> 7bd57fbc4a4d ("vsprintf: don't obfuscate NULL and error pointers")
>
> > ==> The case where symbol addresses are changing.
> >
> > kptr_restrict is set to 2 by default:
> > / # cat /proc/sys/kernel/kptr_restrict
> > 2
> >
> > Basically, the goal is:
> > * To understand how addresses are changing in 4.14 Kernel (without
> > KASLR support)?
> > * Is it possible to support the same in 4.9 Kernel ?
>
> Try setting kptr_restrict to 0 and see if the symbol addresses change? I
> suspect Ard is correct: there's no KASLR here, just hashed pointers
> behaving weird on an old non-stock kernel. :)
>

Okay. Thank you so much for your comments and suggestions.
You mean to say, setting kptr_restrict to 0 may avoid changing symbol
addresses in 4.14 ?
And, sorry, I could not understand the thing about this "hashed pointers".
How can I check this behavior in source code to understand better?
Is it possible to give some reference ?
I wanted to disable this hash pointer on 4.14 kernel and check the behavior.
Also if possible, we would like to make this similar change on 4.9
kernel as well.


Thanks,
Pintu

Re: KASLR support on ARM with Kernel 4.9 and 4.14

[Pintu Agarwal]

On Sat, 26 Sep 2020 at 05:17, Kees Cook  wrote:
> >
> > For a 3/1 split ARM kernel of the typical size, all kernel virtual
> > addresses start with 0xc0, and given that the kernel is located at the
> > start of the linear map, those addresses cannot change even if you
> > move the kernel around in physical memory.
>
> I wonder if this is an Android Common kernel? I think there was %p
> hashing in there before v4.15, but with a different implementation...
>

Hi,
Thank you all for all your reply and comments so far!
Here are some follow-up replies.

>> What device is this? Is it a stock kernel?
This is a Qualcomm Snapdragon Automotive board one with Linux Kernel
4.9 and one with 4.14.

>> Is the boot loader changing the base address? (What boot loader are you
>> using?)
Ohh I did not knew that the bootloader can also change the base address.
I think it uses UEFI.
How to check if bootloader is doing this ?
BTW, both 4.9 board and 4.14 board, uses same bootloader.

>> I wonder if this is an Android Common kernel?
It uses the below kernel for 4.14:
https://gitlab.com/quicla/kernel/msm-4.14/-/tree/LE.UM.3.4.2.r1.5  (or
similar branch).
==> The case where symbol addresses are changing.

kptr_restrict is set to 2 by default:
/ # cat /proc/sys/kernel/kptr_restrict
2

Basically, the goal is:
* To understand how addresses are changing in 4.14 Kernel (without
KASLR support)?
* Is it possible to support the same in 4.9 Kernel ?

--
Thanks,
Pintu

KASLR support on ARM with Kernel 4.9 and 4.14

[Pintu Agarwal]

Hi All,

This is regarding the KASLR feature support on ARM for the kernel
version 4.9 and 4.14.

Is KASLR supported on ARM-32 Linux 4.9 and above ?
Is it dependent on CONFIG_RANDOMIZE_BASE or
/proc/sys/kernel/randomize_va_space ?
Is there any relation between these two?
Is the changing kernel symbols (in every boot), only possible if KASLR
is enabled, or there is another way it can happen?

I have these queries because,
In one of the arm-32 devices with Kernel 4.14, I observed that
CONFIG_RANDOMIZE_BASE is not available.
But /proc/sys/kernel/randomize_va_space is set to 2.
However, I also observed that symbol addresses are changing in every boot.

1st boot cycle:
[root ~]# cat /proc/kallsyms | grep "sys_open"
a5b4de92 T sys_open
[root@sa515m ~]#

2nd boot cycle:
[root ~]# cat /proc/kallsyms | grep "sys_open"
f546ed66 T sys_open

So, I am wondering how this is possible without KASLR
(CONFIG_RANDOMIZE_BASE) support in Kernel ?

Similarly, with Kernel 4.9 and CONFIG_RANDOMIZE_BASE is not available
but /proc/sys/kernel/randomize_va_space is set to 2.
But here, the addresses are remaining same.

1st Run:
[root~]# cat /proc/kallsyms | grep "sys_open"
c01ed68c T sys_open
[root ~]#

*** reboot ***
[root ~]# cat /proc/kallsyms | grep "sys_open"
c01ed68c T sys_open


Is there any other difference between these two kernel versions with
respect to changing symbol addresses ?

Thanks,
Pintu

[PATCH] mm/slab.h: Fix duplicate include file kmemleak.h

[Pintu Kumar]

As I was browsing through this code, I found that linux/kmemleak.h
was declared twice.

When I run ./scripts/checkincludes.pl it reported the same:
mm/slab.h: linux/kmemleak.h is included more than once.

Thus removing the last included header.

Signed-off-by: Pintu Kumar 
---
 mm/slab.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/mm/slab.h b/mm/slab.h
index 6cc323f..95e5cc1 100644
--- a/mm/slab.h
+++ b/mm/slab.h
@@ -46,7 +46,6 @@ struct kmem_cache {
 #include 
 #include 
 #include 
-#include 
 
 /*
  * State of the slab allocator.
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: Generic way for verifying GPIO wakeup capability

[Pintu Agarwal]

On Tue, 9 Jun 2020 at 23:06, Pintu Agarwal  wrote:
>
> Hi All,
>
> I am looking for ways to wakeup any devices (from sleep) using any
> arbitrary gpio wakeup method in a generic way (either from user space
> or kernel space) that should work on any kernel version (starting from
> 4.14 onwards).
>
> What are the options available right now ?
> I wanted to experiment with all of them and decide which is best for us.
>
> Is /sys/class/gpio/ method still valid with the latest kernel ?
> Or is there any other method to do it from user space ?
>
> One option I know is to use enable/disable_irq_wake() API from kernel
> driver suspend/resume path.
> Just like this:
> https://lwn.net/Articles/569027/
>
> But this requires an additional kernel driver and device-tree changes
> for each gpio wakeup, which the end-user needs to implement on their
> own.
>
> Is there any other existing generic mechanism?
>

https://embeddedbits.org/new-linux-kernel-gpio-user-space-interface/

Is it possible to achieve this using this new interface ?

And I think another option is to use gpio-keys defined in device-tree.
Will this method work for any wake-capable gpio ?
How to verify this for any arbitrary gpio ?

Generic way for verifying GPIO wakeup capability

[Pintu Agarwal]

Hi All,

I am looking for ways to wakeup any devices (from sleep) using any
arbitrary gpio wakeup method in a generic way (either from user space
or kernel space) that should work on any kernel version (starting from
4.14 onwards).

What are the options available right now ?
I wanted to experiment with all of them and decide which is best for us.

Is /sys/class/gpio/ method still valid with the latest kernel ?
Or is there any other method to do it from user space ?

One option I know is to use enable/disable_irq_wake() API from kernel
driver suspend/resume path.
Just like this:
https://lwn.net/Articles/569027/

But this requires an additional kernel driver and device-tree changes
for each gpio wakeup, which the end-user needs to implement on their
own.

Is there any other existing generic mechanism?


Thanks,
Pintu

Re: imx6: i2c-transfer timeout issue after resume

[Pintu Agarwal]

On Fri, Oct 4, 2019 at 3:47 PM Pintu Agarwal  wrote:
>
> Hi,
>
> On Sun, Sep 29, 2019 at 10:24 PM Pintu Agarwal  wrote:
> >
> > >
> > > On Mon, Sep 23, 2019 at 1:28 PM Pintu Agarwal  
> > > wrote:
> > > >
> > > > Dear Philipp,
> > > >
> > > > I have a iMX6dl custom board with custom Linux Kernel 4.8.
> > > > I have both LCD and HDMI connected to the board.
> > > > And we are using weston/wayland as the display interface.
> > > > In normal boot, both LCD and HDMI display is working fine.
> > > >
> > > > But, currently, for one of the requirement, I am trying to explore and
> > > > support hibernation image booting on it.
> > > > Currently, we are able to resume the system without display.
> > > > Also, if we make the entire imx-drm as modules, and then install the
> > > > modules after resume, even LCD is also coming up.
> > > > But HDMI display is black out.
> > > >
>
> I just found the main root cause of the HDMI screen blackout issue
> after system resume.
> * HDMI is trying to get EDID data from the monitor using I2C interface.
> * But its seems i2c_transfer is getting timeout after 5 retries.
> * Thus EDID data is failing, and HDMI could not able to detect the monitor.
>
> This is the logs:
>
> [  441.104989] [drm:drm_helper_probe_single_connector_modes]
> [CONNECTOR:29:HDMI-A-1] status updated from unknown to connected
> [  441.116080]: drm_helper_probe_single_connector_modes - inside -
> else override_edid
> [  441.124416]: drm_helper_probe_single_connector_modes - inside -
> else - drm_load_edid_firmware: count: 0
> [  441.134546]: drm_helper_probe_single_connector_modes - calling - get_modes
> [  441.142157]: dw_hdmi_connector_get_modes : called
> [  441.147652]: dw_hdmi_connector_get_modes : called - calling -> drm_get_edid
> [  441.155346]: drm_do_probe_ddc_edid : called!
> [  441.660759]: drm_do_probe_ddc_edid : i2c_transfer: ret: -110, retry: 5
> [  442.170758]: drm_do_probe_ddc_edid : i2c_transfer: ret: -110, retry: 4
> [  442.680755]: drm_do_probe_ddc_edid : i2c_transfer: ret: -110, retry: 3
> [  443.190755]: drm_do_probe_ddc_edid : i2c_transfer: ret: -110, retry: 2
> [  443.700754]: drm_do_probe_ddc_edid : i2c_transfer: ret: -110, retry: 1
> [  443.707989]: drm_get_edid : called - drm_probe_ddc - failed
> [  443.714303] dwhdmi-imx 12.hdmi: failed to get edid
>
> Is there any clue, how to resolve this i2c failure issue, after resume?
> This does not happen in normal booting case.
>
> These are the steps I follow:
> * Boot the system normally (without display) and install all imx-drm as 
> modules.
> * Then uninstall the modules in reverse order.
> * Take the snapshot of the system (suspend to disk).
> * Reboot the system and boot with the image.
> * Install all the modules again.
> * Then launch the Weston.
> * During the weston launch in the beginning we observe this error.
>

* Changing the subject to be more relevant.

I need some pointers in debugging this i2c_transfer timeout issue,
after system resume.
I am not so much familiar with i2c, so I am looking for some clue here.

i2c-experts (or pm experts), please help me to find the root cause and
debug further.

Thanks,
Pintu

Re: imx6: hdmi black screen issue after resume

[Pintu Agarwal]

>
> On Mon, Sep 23, 2019 at 1:28 PM Pintu Agarwal  wrote:
> >
> > Dear Philipp,
> >
> > I have a iMX6dl custom board with custom Linux Kernel 4.8.
> > I have both LCD and HDMI connected to the board.
> > And we are using weston/wayland as the display interface.
> > In normal boot, both LCD and HDMI display is working fine.
> >
> > But, currently, for one of the requirement, I am trying to explore and
> > support hibernation image booting on it.
> > Currently, we are able to resume the system without display.
> > Also, if we make the entire imx-drm as modules, and then install the
> > modules after resume, even LCD is also coming up.
> > But HDMI display is black out.
> >
> > After, resume, when I try to launch the weston, I noticed the following 
> > errors:
> > enabling vblank on crtc 0, ret: 0
> > drm_vblank_get: CALLED: vblank->refcount: 1
> > [ cut here ]
> > WARNING: at drivers/gpu/drm/drm_atomic_helper.c:1121
> > drm_atomic_helper_wait_for_vblanks+0x228/0x24c [drm_kms_helper]()
> > [CRTC:24] vblank wait timed out
> > .
> > [drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]] *ERROR*
> > [CRTC:24:crtc-0] flip_done timed out
> >
> > 
> > [00:06:42.600] Warning: computed repaint delay is insane: -5069 msec
> > [00:06:42.665] unexpectedly large timestamp jump (from 397522 to 402648)
> > 
> >
> > And, when I try to reboot the system, the system does not reboot.
> > And I get the following error:
> > /wayland # reboot
> > 
> > [17:55:01.180] destroy output while page flip pending
> > ...
> > imx-ipuv3 240.ipu: DC stop timeout after 50 ms
> >
> >
> > -
> > If you have any clue about this issue, please let me know.
> >
> > Any help will be really appreciated!
> >
> >
> > Thank You!
> >
> > Regards,
> > Pintu


Hi All,

I need some help, on the above issue.
Finally, I could boil down the issue to be vblank refcount issue.
After system resume, vblank ref count is getting screwed up, because
of which vblank_enable is not happening.
As per below code path: drivers/gpu/drm/drm_vblank.c:
drm_vblank_get()
{
[...]
/* Going from 0->1 means we have to enable interrupts again */
if (atomic_add_return(1, >refcount) == 1) {
ret = drm_vblank_enable(dev, pipe);
} else {
if (!vblank->enabled) {
atomic_dec(>refcount);
ret = -EINVAL;
}
}
[...]
First time, everything seems fine.
drm_vblank_get: CALLED: pipe: 0, vblank->refcount: 0, vblank-enabled: 0
..
drm_vblank_enable: calling - enable_vblank
enabling vblank on crtc 0, ret: 0
...

But, after resume, somewhere during HDMI initialization, the refcount
is getting incremented.
drm_vblank_get: CALLED: pipe: 0, vblank->refcount: 1, vblank-enabled: 1
Thus, due to the above logic, drm_vblank_enable() will not be called,
if previous refcount is not 0.

What I further noticed is that, after resume, during hdmi_setup the
refcount is automatically getting updated.
drm_update_vblank_count - storing vblank count: diff: 1

This does not happen in normal case.
Now, I am not sure, why the vblank counter is getting incremented
during hdmi setup.
Is it like, hdmi setup is taking slightly longer time for
initialization, after resume??
Because of which the vblank timestamp counter is getting disturbed.

If anybody observed this issue, or aware about the fixes, please let me know.
It will be of great help.

Meanwhile, I am further continue to debug this more..

Regards,
Pintu

Re: Let's talk about the elephant in the room - the Linux kernel's inability to gracefully handle low memory pressure

[Pintu Agarwal]

es sluggish.
  So, I was thinking to add new entry to capture task details as well.


These are some of my opinion. It may or may not be applicable directly.
Further brain-storming or discussions might be required.



Regards,
Pintu

Re: Pause a process execution from external program

[Pintu Agarwal]

On Fri, Jun 14, 2019 at 1:13 AM Valdis Klētnieks
 wrote:
>
> On Thu, 13 Jun 2019 13:22:12 +0530, Shyam Saini said:
>
> > from command line we use ctrl-z to stop execution of a foreground
> > process but you can program
> > SIGTSTP signal handler in your application code to do the same.
>
> Note that if you simply fail to include a signal handler for SIGSTOP and
> SIGCONT, it will Do The Right Thing.  The only programs that need worry about
> SIGTSTP are ones like 'vi' that may want to do something (like restore the
> terminal state from raw to cooked mode, etc) before they stop.  That's why you
> can control-z /bin/cat without it having to include a signal handler for it.
>
> % kill -STOP `pidof process-to-stop`   # stop it
> % kill -CONT `pidof process-to-stop`  # and make it run again.
>
> No source code modifications needed.  No source needed.
>
> Now, if you want to make it stop at a *specific point*, then you're into
> ptrace territory, and source will be helpful.
>
Yes, I think ptrace can serve our purpose.
Thank you so much.

Pause a process execution from external program

[Pintu Agarwal]

Hi All,
I was just wondering if this is possible in the Linux world.
My requirement is:
For some reason, I want to halt/pause the execution (for some
specified time) of a running process/thread (at some location),
without modified the source, may be by firing some events/signals from
an another external program, by specifying the address location or a
line number.

Is this possible ?
May be by using some system call, or other mechanism using the process PID.
Assume that its a debugging system with all root privileges.

Basically, its just like how "gdb" is able to set the break-point in a
program, and able to stop its execution exactly at that location.
I am wondering what mechanism "gdb" uses to do this?
I tried to check here, but could find the exact place, where this is handled:
https://github.com/bminor/binutils-gdb/blob/master/gdb/breakpoint.c

Unfortunately, I cannot use "gdb", but I wanted to borrow this
mechanism only to serve my purpose.

If anyone is aware, please let me know.
I will share my findings here, after I get some useful results of my
experimentation.

Thank you for your help!


Regards,
Pintu

Building and cross-compiling kernel source on Mac OS

[Pintu Agarwal]

Hi,

I have a Mac Book Pro with macOS High Sierra 10.13.x installed (with
Mac OS Extended (Journaled, Encrypted)).
I also have the Xcode installed so I can compile a C program using gcc.

Now, I wanted to build linux kernel code (cross compile for arm or
risc-v) on Mac OS.
I know this is possible, but I am not familiar with the steps.
If somebody have the step by step guide, please share.

If this works, then I don't need to use Virtual Box inside MAC to
build the kernel code.


Thanks,
Pintu

Re: arm64 Kernel build for qemu-system-aarch64 ?

[Pintu Agarwal]

On Fri, Feb 22, 2019 at 7:41 PM Mark Rutland  wrote:
>
> On Fri, Feb 22, 2019 at 07:17:00PM +0530, Pintu Agarwal wrote:
> > Hi All,
>
> Hi,
>
> > I want to build Linux Kernel 4.20 for arm64 and use it on qemu-arm64.
> > I see that there is a defconfig available in arch/arm64/configs/defconfig
> > But I am not sure whether it will work for qemu-arm64, and by default
> > which machine type is supported.
> >
> > I already have working setup for qemu-arm for both versatile and
> > vexpress machine. There is already a defconfig available for these
> > under arch/arm.
> > So I can build the kernel for it.
> >
> > But, whether these defconfig are supported for arm64 ?
> > If anybody have setup for qemu-arm64 kernel, please share the steps.
> > About rootfs, I am planning to use the arm32 version of busybox itself.
>
> The arm64 defconfig is intended to work for all platforms.
>
> I use that with qemu's '-machine virt'. Assuming you use virtio-net and
> virtio-block, no additional drivers are required.
>
> For example, I can boot a defconfig kernel using the followign QEMU options:
>
> qemu-system-aarch64 \
> -m 2048 -smp 4 \
> -net nic \
> -net user,host=10.0.2.10,hostfwd=tcp::65022-:22 \
> -nographic \
> -no-reboot \
> -machine virt,accel=kvm,gic_version=host \
> -cpu host \
> -hda ${FILESYSTEM} \
> -snapshot \
> -kernel ${KERNEL} \
> -append "earlycon root=/dev/vda panic_on_warn"
>
> Thanks,
> Mark.

oh thank you so much for your information.
I was exactly looking for this option.
Let me try it on Monday.


Thanks

arm64 Kernel build for qemu-system-aarch64 ?

[Pintu Agarwal]

Hi All,

I want to build Linux Kernel 4.20 for arm64 and use it on qemu-arm64.
I see that there is a defconfig available in arch/arm64/configs/defconfig
But I am not sure whether it will work for qemu-arm64, and by default
which machine type is supported.

I already have working setup for qemu-arm for both versatile and
vexpress machine. There is already a defconfig available for these
under arch/arm.
So I can build the kernel for it.

But, whether these defconfig are supported for arm64 ?
If anybody have setup for qemu-arm64 kernel, please share the steps.
About rootfs, I am planning to use the arm32 version of busybox itself.


Thanks,
Pintu

Re: BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:65

[Pintu Agarwal]

Hello Sai,

Thanks so much for your help.

On Thu, Feb 14, 2019 at 12:14 AM Sai Prakash Ranjan
 wrote:
>
> Hi,
>
> On 2/13/2019 8:10 PM, Pintu Agarwal wrote:
> > OK thanks for your suggestions. sdm845-perf_defconfig did not work for
> > me. The target did not boot.
>
> Perf defconfig works fine. You need to enable serial console with below
> config added to perf defconfig.
>
> CONFIG_SERIAL_MSM_GENI_CONSOLE=y
>
Actually for me the kernel does not boot. It stuck in bootloader, with
"valid dtb not found".
I did not debug it further.
Anyways, we can look into this issue later.

> > However, disabling CONFIG_PANIC_ON_SCHED_BUG works, and I got a root
> > shell at least.
>
> >
> > But this seems to be a work around.
> > I still get a back trace in kernel logs from many different places.
> > So, it looks like there is some code in qualcomm specific drivers that
> > is calling a sleeping method from invalid context.
> > How to find that...
> > If this fix is already available in latest version, please let me know.
> >
>
> Seems like interrupts are disabled when down_write_killable() is called.
> It's not the drivers that is calling the sleeping method which can  be
> seen from the log.
>
> [   22.140224] [] ___might_sleep+0x140/0x188
> [   22.145862] [] __might_sleep+0x58/0x90 <---
> [   22.151249] [] down_write_killable+0x2c/0x80   <---
> [   22.157155] [] setup_arg_pages+0xb8/0x208  <---
> [   22.162792] [] load_elf_binary+0x434/0x1298
> [   22.168600] [] search_binary_handler+0xac/0x1f0
> [   22.174763] []
> do_execveat_common.isra.15+0x504/0x6c8
> [   22.181452] [] do_execve+0x44/0x58
> [   22.186481] [] run_init_process+0x38/0x48  <---
> [   22.192122] [] kernel_init+0x8c/0x108
> [   22.197411] [] ret_from_fork+0x10/0x50
>
Yes, these are generic API, and I don't expect any changes in here.
We don't have this issue in another SOC 4.9 kernel.
Also I compared these APIs with mainline and there is no major changes here.
This is just one example.
This sleep issue is happening from other places as well.
May be one common similarity may be: during task loading, or switching.

>  >
>  > This at least proves that there is no issue in core ipipe patches, and
>  > I can proceed.
>
> I doubt the *IPIPE patches*. You said you removed the configs, but all
> code are not under IPIPE configs and as I see there are lots of
> changes to interrupt code in general with ipipe.
>
We observed that this issue is happening in normal sdm845 kernel as
well (without ipipe/xenomai patches applied in another branch).
Another point is, we don't see this issue in another arm64 target such
as hikey, with same 4.9 kernel.

> So to actually confirm whether the issue is with qcom drivers or ipipe,
> please *remove ipipe patches (not just configs)* and boot.
> Also paste the full dmesg logs for these 2 cases(with and without
> ipipe).
>
hmmm. This will be little tough.
I will try to find sometime to point the exact cause, and share findings here.
Currently, I am debugging another issue.

Thanks for your help.


Regards

Re: BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:65

[Pintu Agarwal]

On Wed, Feb 13, 2019 at 3:21 PM Sai Prakash Ranjan
 wrote:
>
> Hi Pintu,
>
> On 2/13/2019 2:04 PM, Pintu Agarwal wrote:
> >
> > This is the complete logs at the time of crash:
> >
> > [   21.681020] VFS: Mounted root (ext4 filesystem) readonly on device 8:6.
> > [   21.690441] devtmpfs: mounted
> > [   21.702517] Freeing unused kernel memory: 6528K
> > [   21.75] BUG: sleeping function called from invalid context at
> > kernel/locking/rwsem.c:65
> > [   21.775108] in_atomic(): 0, irqs_disabled(): 128, pid: 1, name: init
> > [   21.781532] [ cut here ]
> > [   21.786209] kernel BUG at kernel/sched/core.c:8490!
> > [   21.791157] [ cut here ]
> > [   21.795831] kernel BUG at kernel/sched/core.c:8490!
> > [   21.800763] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> > [   21.806319] Modules linked in:
> > [   21.809474] CPU: 0 PID: 1 Comm: init Not tainted 4.9.103+ #115
> > [   21.815375] Hardware name: Qualcomm Technologies, Inc. MSM 
> > [   21.822584] task: ffe330440080 task.stack: ffe330448000
> > [   21.828584] PC is at ___might_sleep+0x140/0x188
> > [   21.833175] LR is at ___might_sleep+0x128/0x188
> > [   21.837759] pc : [] lr : []
> > pstate: 604001c5
>
> 
>
> >  ffe33044b8d0
> > [   22.135279] bac0: 0462 0006
> > [   22.140224] [] ___might_sleep+0x140/0x188
> > [   22.145862] [] __might_sleep+0x58/0x90
> > [   22.151249] [] down_write_killable+0x2c/0x80
> > [   22.157155] [] setup_arg_pages+0xb8/0x208
> > [   22.162792] [] load_elf_binary+0x434/0x1298
> > [   22.168600] [] search_binary_handler+0xac/0x1f0
> > [   22.174763] [] do_execveat_common.isra.15+0x504/0x6c8
> > [   22.181452] [] do_execve+0x44/0x58
> > [   22.186481] [] run_init_process+0x38/0x48
> > [   22.192122] [] kernel_init+0x8c/0x108
> > [   22.197411] [] ret_from_fork+0x10/0x50
> > [   22.202790] Code: b9453800 0b20 6b00027f 54c1 (d421)
> > [   22.208965] ---[ end trace d775a851176a61ec ]---
> > [   22.220051] Kernel panic - not syncing: Attempted to kill init!
> > exitcode=0x000b
> >
>
> This might be the work of CONFIG_PANIC_ON_SCHED_BUG which is extra debug
> option enabled in *sdm845_defconfig*. You can disable it or better
> I would suggest to use *sdm845-perf_defconfig* instead of
> sdm845_defconfig since there are a lot of debug options enabled
> in the latter which may be not compatible when IPIPE patches
> are applied.

OK thanks for your suggestions. sdm845-perf_defconfig did not work for
me. The target did not boot.
However, disabling CONFIG_PANIC_ON_SCHED_BUG works, and I got a root
shell at least.
This at least proves that there is no issue in core ipipe patches, and
I can proceed.

But this seems to be a work around.
I still get a back trace in kernel logs from many different places.
So, it looks like there is some code in qualcomm specific drivers that
is calling a sleeping method from invalid context.
How to find that...
If this fix is already available in latest version, please let me know.

Thanks,
Pintu

BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:65

[Pintu Agarwal]

Hi,

I need some pointer in debugging the root cause of this issue.
BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:65
[   22.140224] [] ___might_sleep+0x140/0x188
[   22.145862] [] __might_sleep+0x58/0x90
[   22.151249] [] down_write_killable+0x2c/0x80
[   22.157155] [] setup_arg_pages+0xb8/0x208
[   22.162792] [] load_elf_binary+0x434/0x1298
[   22.168600] [] search_binary_handler+0xac/0x1f

I am using msm-4.9.103 kernel on some qualcomm reference platform:
https://source.codeaurora.org/quic/la/kernel/msm-4.9/tree/?h=CogSystems-msm-49/msm-4.9
Then I applied Xenomai/ipipe arm64 patches for kernel 4.9 on top of
it, but later disabled it.
But I get this sleeping issue even after disabling the Xenomai
configs. I expect the behavior should be similar to normal kernel
after disabling it.
AFAIK all the above callbacks are from normal mainline kernel, so
there should not be any issue, as it was working previously.

So, if anybody have debugged this issue earlier, please share your
findings about what can cause this type of issue.
It happens just during rootfs mounting and all above callback looks
normal to me.
Even I compared their implementation with mainline code and it looks
almost same.

So, I guess it might be triggering from somewhere else, may be from
interrupt context.
So, I am looking for ways to pin-point the exact place, and resolve this issue.
Any pointers will be highly appreciated.


This is the complete logs at the time of crash:

[   21.681020] VFS: Mounted root (ext4 filesystem) readonly on device 8:6.
[   21.690441] devtmpfs: mounted
[   21.702517] Freeing unused kernel memory: 6528K
[   21.75] BUG: sleeping function called from invalid context at
kernel/locking/rwsem.c:65
[   21.775108] in_atomic(): 0, irqs_disabled(): 128, pid: 1, name: init
[   21.781532] [ cut here ]
[   21.786209] kernel BUG at kernel/sched/core.c:8490!
[   21.791157] [ cut here ]
[   21.795831] kernel BUG at kernel/sched/core.c:8490!
[   21.800763] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[   21.806319] Modules linked in:
[   21.809474] CPU: 0 PID: 1 Comm: init Not tainted 4.9.103+ #115
[   21.815375] Hardware name: Qualcomm Technologies, Inc. MSM 
[   21.822584] task: ffe330440080 task.stack: ffe330448000
[   21.828584] PC is at ___might_sleep+0x140/0x188
[   21.833175] LR is at ___might_sleep+0x128/0x188
[   21.837759] pc : [] lr : []
pstate: 604001c5
[   21.845228] sp : ffe33044bba0
[   21.848590] x29: ffe33044bba0 x28: ffe321580680
[   21.854045] x27: ffe32df6f780 x26: ffe32155db80
[   21.859495] x25: ffe3215980c0 x24: 0001
[   21.864954] x23: ffe321598040 x22: ff88baaaf000
[   21.870410] x21: ff88b91f50d4 x20: ffe330440080
[   21.875858] x19:  x18: ff88baaafb08
[   21.881313] x17: cea8ef66 x16: f32c652b
[   21.886759] x15: ff893ace16f7 x14: 0006
[   21.892209] x13: ff88bace1705 x12: 0007
[   21.897671] x11: 0006 x10: 0462
[   21.903122] x9 : ffe33044b8d0 x8 : 
[   21.908581] x7 : ff88baaafb08 x6 : 2ec8289a
[   21.914029] x5 : 0015 x4 : 00f2e11f
[   21.919488] x3 : 0004 x2 : 3f188ee06c84b500
[   21.924949] x1 :  x0 : 
[   21.930407]
[   21.930407] PC: 0xff88b8ce6568:
[   21.935432] 6568  f9401a81 d28dd3a0 f2aaf580 f9400021 eb3f
54000181 d53b4220 36380060
[   21.944046] 6588  d5384100 94030485 d5384100 b9401001 b9453800
0b20 6b00027f 54c1
[   21.952653] 65a8  d421 d000a180 91242000 9403e085 17f2
b000a180 91376000 9403e081
[   21.961253] 65c8  b000a140 aa1503e2 aa1503e1 910e2000 9403e07c
9000a140 9134 9403e079
[   21.969858]
[   21.969858] LR: 0xff88b8ce6550:
[   21.974884] 6550  b9467a83 1a9f07e1 91214284 12190042 91232000
9403e099 f9401a81 d28dd3a0
[   21.983486] 6570  f2aaf580 f9400021 eb3f 54000181 d53b4220
36380060 d5384100 94030485
[   21.992102] 6590  d5384100 b9401001 b9453800 0b20 6b00027f
54c1 d421 d000a180
[   22.000710] 65b0  91242000 9403e085 17f2 b000a180 91376000
9403e081 b000a140 aa1503e2
[   22.009311]
[   22.009311] SP: 0xffe33044bb60:
[   22.014335] bb60  b8ce6590 ff88 3044bba0 ffe3 b8ce65a8
ff88 604001c5 
[   22.022949] bb80  304408d0 ffe3 0015  
007f baaafb08 ff88
[   22.031554] bba0  3044bbd0 ffe3 b8ce6648 ff88 ba11b8b8
ff88 0041 
[   22.040162] bbc0    2155db80 ffe3 3044bc00
ffe3 b9d43f84 ff88
[   22.048775] Process init (pid: 1, stack limit = 0xffe330448000)
[   22.055108] Call trace:
[   22.057603] Exception stack(0xffe33044b9a0 to 0xffe33044bad0)
[   22.064118] b9a0:  007f
ffe33044bba0 ff88b8ce65a8
[   22.072024] b9c0: 604001c5 003d

Re: Need help: how to locate failure from irq_chip subsystem

[Pintu Agarwal]

On Fri, Jan 18, 2019 at 5:23 PM Sai Prakash Ranjan
 wrote:
>
> On 1/18/2019 4:50 PM, Pintu Agarwal wrote:
> >>>> Could you please tell which QCOM SoC this board is based on?
> >>>>
> >>>
> >>> Snapdragon 845 with kernel 4.9.x
> >>> I want to know from which subsystem it is triggered:drivers/soc/qcom/
> >>>
> >>
> >> Irqchip driver is "drivers/irqchip/irq-gic-v3.c". The kernel you are
> >> using is msm-4.9 I suppose or some other kernel?
> >>
> > Yes, I am using customized version of msm-4.9 kernel based on Android.
> > And yes the irqchip driver is: irq-gic-v3, which I can see from config.
> >
> > But, what I wanted to know is, how to find out which driver module
> > (hopefully under: /drivers/soc/qcom/) that register with this
> > irq_chip, is getting triggered at the time of crash ?
> > So, that I can implement irq_hold function for it, which is the cause of 
> > crash.
> >
>
> Hmm, since this is a bootup crash, *initcall_debug* should help.
> Add "initcall_debug ignore_loglevel" to kernel commandline and
> check the last log before crash.
>

OK thanks Sai, for your suggestions.
Yes, I already tried that, but it did not help much.

Anyways, I could finally find the culprit driver, from where null
reference is coming.
So, that issue is fixed.
But, now I am looking into another issue.
If required, I will post further...

Thanks,
Pintu

Re: Need help: how to locate failure from irq_chip subsystem

[Pintu Agarwal]

> >> Could you please tell which QCOM SoC this board is based on?
> >>
> >
> > Snapdragon 845 with kernel 4.9.x
> > I want to know from which subsystem it is triggered:drivers/soc/qcom/
> >
>
> Irqchip driver is "drivers/irqchip/irq-gic-v3.c". The kernel you are
> using is msm-4.9 I suppose or some other kernel?
>
Yes, I am using customized version of msm-4.9 kernel based on Android.
And yes the irqchip driver is: irq-gic-v3, which I can see from config.

But, what I wanted to know is, how to find out which driver module
(hopefully under: /drivers/soc/qcom/) that register with this
irq_chip, is getting triggered at the time of crash ?
So, that I can implement irq_hold function for it, which is the cause of crash.

Re: Need help: how to locate failure from irq_chip subsystem

[Pintu Agarwal]

On Fri, Jan 18, 2019 at 3:54 PM Sai Prakash Ranjan
 wrote:
>
> Hi Pintu-san,
>
> On 1/18/2019 3:38 PM, Pintu Agarwal wrote:
> > Hi All,
> >
> > Currently, I am trying to debug a boot up crash on some qualcomm
> > snapdragon arm64 board with kernel 4.9.
> > I could find the cause of the failure, but I am unable to locate from
> > which subsystem/drivers this is getting triggered.
> > If you have any ideas or suggestions to locate the issue, please let me 
> > know.
> >
> > This is the snapshot of crash logs:
> > [6.907065] Unable to handle kernel NULL pointer dereference at
> > virtual address 
> > [6.973938] PC is at 0x0
> > [6.976503] LR is at __ipipe_ack_fasteoi_irq+0x28/0x38
> > [7.151078] Process qmp_aop (pid: 24, stack limit = 0xfffbedc18000)
> > [7.242668] [<  (null)>]   (null)
> > [7.247416] [] __ipipe_dispatch_irq+0x78/0x340
> > [7.253469] [] __ipipe_grab_irq+0x5c/0xd0
> > [    7.341538] [] gic_handle_irq+0xc0/0x154
> >
> > [6.288581] [PINTU]: __ipipe_ack_fasteoi_irq - called
> > [6.293698] [PINTU]: __ipipe_ack_fasteoi_irq:
> > desc->irq_data.chip->irq_hold is NULL
> >
> > When I check, I found that the irq_hold implementation is missing in
> > one of the irq_chip driver (expected by ipipe), which I am supposed to
> > implement.
> >
> > But I am unable to locate which irq_chip driver.
> > If there are any good techniques to locate this in kernel, please help.
> >
>
> Could you please tell which QCOM SoC this board is based on?
>

Snapdragon 845 with kernel 4.9.x
I want to know from which subsystem it is triggered:drivers/soc/qcom/

>
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation

Need help: how to locate failure from irq_chip subsystem

[Pintu Agarwal]

Hi All,

Currently, I am trying to debug a boot up crash on some qualcomm
snapdragon arm64 board with kernel 4.9.
I could find the cause of the failure, but I am unable to locate from
which subsystem/drivers this is getting triggered.
If you have any ideas or suggestions to locate the issue, please let me know.

This is the snapshot of crash logs:
[6.907065] Unable to handle kernel NULL pointer dereference at
virtual address 
[6.973938] PC is at 0x0
[6.976503] LR is at __ipipe_ack_fasteoi_irq+0x28/0x38
[7.151078] Process qmp_aop (pid: 24, stack limit = 0xfffbedc18000)
[7.242668] [<  (null)>]   (null)
[7.247416] [] __ipipe_dispatch_irq+0x78/0x340
[7.253469] [] __ipipe_grab_irq+0x5c/0xd0
[7.341538] [] gic_handle_irq+0xc0/0x154

[6.288581] [PINTU]: __ipipe_ack_fasteoi_irq - called
[6.293698] [PINTU]: __ipipe_ack_fasteoi_irq:
desc->irq_data.chip->irq_hold is NULL

When I check, I found that the irq_hold implementation is missing in
one of the irq_chip driver (expected by ipipe), which I am supposed to
implement.

But I am unable to locate which irq_chip driver.
If there are any good techniques to locate this in kernel, please help.


Thanks,
Pintu

Re: Creating compressed backing_store as swapfile

[Pintu Agarwal]

On Mon, Nov 5, 2018 at 9:37 PM Austin S. Hemmelgarn
 wrote:
>
> On 11/5/2018 10:58 AM, Adam Borowski wrote:
> > On Mon, Nov 05, 2018 at 08:31:46PM +0530, Pintu Agarwal wrote:
> >> Hi,
> >>
> >> I have one requirement:
> >> I wanted to have a swapfile (64MB to 256MB) on my system.
> >> But I wanted the data to be compressed and stored on the disk in my 
> >> swapfile.
> >> [Similar to zram, but compressed data should be moved to disk, instead of 
> >> RAM].
> >>
> >> Note: I wanted to optimize RAM space, so performance is not important
> >> right now for our requirement.
> >>
> >> So, what are the options available, to perform this in 4.x kernel version.
> >> My Kernel: 4.9.x
> >> Board: any - (arm64 mostly).
> >>
> >> As I know, following are the choices:
> >> 1) ZRAM: But it compresses and store data in RAM itself
> >> 2) frontswap + zswap : Didn't explore much on this, not sure if this
> >> is helpful for our case.
> >> 3) Manually creating swapfile: but how to compress it ?
> >> 4) Any other options ?
> >
> > Loop device on any filesystem that can compress (such as btrfs)?  The
> > performance would suck, though -- besides the indirection of loop, btrfs
> > compresses in blocks of 128KB while swap wants 4KB writes.  Other similar
> > option is qemu-nbd -- it can use compressed disk images and expose them to a
> > (local) nbd client.
>
> Swap on any type of a networked storage device (NBD, iSCSI, ATAoE, etc)
> served from the local system is _really_ risky.  The moment the local
> server process for the storage device gets forced out to swap, you deadlock.
>
> Performance isn't _too_ bad for the BTRFS case though (I've actually
> tested this before), just make sure you disable direct I/O mode on the
> loop device, otherwise you run the risk of data corruption.

Sorry, btrfs is not an option for us. We want something more lighter
weight as our requirement is just < 200 MBs.

Re: Creating compressed backing_store as swapfile

[Pintu Agarwal]

On Mon, Nov 5, 2018 at 9:37 PM Austin S. Hemmelgarn
 wrote:
>
> On 11/5/2018 10:58 AM, Adam Borowski wrote:
> > On Mon, Nov 05, 2018 at 08:31:46PM +0530, Pintu Agarwal wrote:
> >> Hi,
> >>
> >> I have one requirement:
> >> I wanted to have a swapfile (64MB to 256MB) on my system.
> >> But I wanted the data to be compressed and stored on the disk in my 
> >> swapfile.
> >> [Similar to zram, but compressed data should be moved to disk, instead of 
> >> RAM].
> >>
> >> Note: I wanted to optimize RAM space, so performance is not important
> >> right now for our requirement.
> >>
> >> So, what are the options available, to perform this in 4.x kernel version.
> >> My Kernel: 4.9.x
> >> Board: any - (arm64 mostly).
> >>
> >> As I know, following are the choices:
> >> 1) ZRAM: But it compresses and store data in RAM itself
> >> 2) frontswap + zswap : Didn't explore much on this, not sure if this
> >> is helpful for our case.
> >> 3) Manually creating swapfile: but how to compress it ?
> >> 4) Any other options ?
> >
> > Loop device on any filesystem that can compress (such as btrfs)?  The
> > performance would suck, though -- besides the indirection of loop, btrfs
> > compresses in blocks of 128KB while swap wants 4KB writes.  Other similar
> > option is qemu-nbd -- it can use compressed disk images and expose them to a
> > (local) nbd client.
>
> Swap on any type of a networked storage device (NBD, iSCSI, ATAoE, etc)
> served from the local system is _really_ risky.  The moment the local
> server process for the storage device gets forced out to swap, you deadlock.
>
> Performance isn't _too_ bad for the BTRFS case though (I've actually
> tested this before), just make sure you disable direct I/O mode on the
> loop device, otherwise you run the risk of data corruption.

Sorry, btrfs is not an option for us. We want something more lighter
weight as our requirement is just < 200 MBs.

Re: KSM not working in 4.9 Kernel

[Pintu Kumar]

Hi,

Thank you so much for all your reply so far.
I have few more doubts to understand the output from ksm sysfs.
Device: Hikey620 - ARM64 - Linux 4.9.20
With HUGE page enabled:
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set

Currently, I get this output, when I run below program with ksm:

~ # grep -H '' /sys/kernel/mm/ksm/*
/sys/kernel/mm/ksm/full_scans:29
/sys/kernel/mm/ksm/page_comparisons:39584
/sys/kernel/mm/ksm/pages_hashed:11672
/sys/kernel/mm/ksm/pages_scanned:21766
/sys/kernel/mm/ksm/pages_shared:3
/sys/kernel/mm/ksm/pages_sharing:10097
/sys/kernel/mm/ksm/pages_to_scan:200
/sys/kernel/mm/ksm/pages_unshared:53
/sys/kernel/mm/ksm/pages_volatile:1
/sys/kernel/mm/ksm/run:0
/sys/kernel/mm/ksm/sleep_millisecs:1000
---

int main(int argc, char *argv[])
{
int i, n, size, ret;
char *buffer;
void *addr;

n = 100;
size = 100 * getpagesize();
for (i = 0; i < n; i++) {
buffer = (char *)malloc(size);
memset(buffer, 0xff, size);
madvise(buffer, size, MADV_MERGEABLE);
if (ret < 0) {
fprintf(stderr, "malloc madvise failed: ret:
%d, reason: %s\n", ret, strerror(errno));
}
usleep(500);
}
printf("Donepress ^C\n");
pause();
return 0;
}
Note: madvise() system call is not failing here, as mentioned earlier.
I guess the page is aligned with getpagesize().
Then I do this to invoke ksm:
# echo 1 > /sys/kernel/mm/ksm/run
# ./malloc-test.out &
# sleep 5
# echo 0 > /sys/kernel/mm/ksm/run
#

Also, the anon pages in the system shows like this:
BEFORE:
-
~ # cat /proc/meminfo | grep -i anon
Active(anon):  40740 kB
Inactive(anon):0 kB
AnonPages: 40760 kB
AnonHugePages: 0 kB

AFTER MERGING:
--
~ # cat /proc/meminfo | grep -i anon
Active(anon):440 kB
Inactive(anon):0 kB
AnonPages:   188 kB
AnonHugePages: 0 kB

I want to understand the KSM output w.r.t to the above program, and
cross-check if the output is correct.
Can someone help me to understand it?

As of now, what I understood is that:
- I am allocating around 400KB of memory 100 times. That is: 100 * 100
* 4K = 1 pages (which are all with similar content).
- Output says: 10097 page_sharing happened.
- Pages currently shared is: 3
- So total pages are: 10097 + 3 = 10100

I could not understand from where the additional 100 pages came from?
Also, why some pages are shown as: pages_unshared ?
What can I interpret from this?
And, what does it mean by: pages_volatile:1 ?

Basically, I wanted to understand, is there any problem with the above
output, or it is fine.
If it is fine, how to prove it?



Thanks,
Pintu

On Mon, Sep 17, 2018 at 8:29 PM Mike Rapoport  wrote:
>
> On Mon, Sep 17, 2018 at 05:25:27PM +0530, Pintu Kumar wrote:
> > On Mon, Sep 17, 2018 at 11:46 AM Pintu Kumar  wrote:
> > > > > But still no effect.
> > > > > And I checked LTP test cases. It almost doing the same thing.
> > > > >
> > > > > I observed that [ksmd] thread is not waking up at all.
> > > > > I gave some print inside it, but I could never saw that prints coming.
> > > > > I could not find it running either in top command during the 
> > > > > operation.
> > > > > Is there anything needs to be done, to wakw up ksmd?
> > > > > I already set: echo 1 > /sys/kernel/mm/ksm.
> > > >
> > > > It should be echo 1 > /sys/kernel/mm/ksm/run
> > > >
> > >
> > > Oh yes, sorry for the typo.
> > > I tried the same, but still ksm is not getting invoked.
> > > Could someone confirm if KSM was working in 4.9 kernel?
> > >
> >
> > Ok, it's working now. I have to explicitly stop the ksm thread to see
> > the statistics.
> > Also there was some internal patch that was setting vm_flags to
> > VM_MERGABLE thus causing ksm_advise call to return.
> >
> > # echo 1 > /sys/kernel/mm/ksm/run
> > # ./malloc-test.out &
> > # echo 0 > /sys/kernel/mm/ksm/run
> >
> > ~ # grep -H '' /sys/kernel/mm/ksm/*
> > /sys/kernel/mm/ksm/full_scans:105
> > /sys/kernel/mm/ksm/pages_shared:1
> > /sys/kernel/mm/ksm/pages_sharing:999
> > /sys/kernel/mm/ksm/pages_to_scan:100
> > /sys/kernel/mm/ksm/pages_unshared:0
> > /sys/kernel/mm/ksm/pages_volatile:0
> > /sys/kernel/mm/ksm/run:0
> > /sys/kernel/mm/ksm/sleep_millisecs:20
> >
> >
> > However, I have one doubt.
> > Is the above data correct, for the below program?
>
> You have 1 shared page and 999

Re: KSM not working in 4.9 Kernel

[Pintu Kumar]

Hi,

Thank you so much for all your reply so far.
I have few more doubts to understand the output from ksm sysfs.
Device: Hikey620 - ARM64 - Linux 4.9.20
With HUGE page enabled:
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set

Currently, I get this output, when I run below program with ksm:

~ # grep -H '' /sys/kernel/mm/ksm/*
/sys/kernel/mm/ksm/full_scans:29
/sys/kernel/mm/ksm/page_comparisons:39584
/sys/kernel/mm/ksm/pages_hashed:11672
/sys/kernel/mm/ksm/pages_scanned:21766
/sys/kernel/mm/ksm/pages_shared:3
/sys/kernel/mm/ksm/pages_sharing:10097
/sys/kernel/mm/ksm/pages_to_scan:200
/sys/kernel/mm/ksm/pages_unshared:53
/sys/kernel/mm/ksm/pages_volatile:1
/sys/kernel/mm/ksm/run:0
/sys/kernel/mm/ksm/sleep_millisecs:1000
---

int main(int argc, char *argv[])
{
int i, n, size, ret;
char *buffer;
void *addr;

n = 100;
size = 100 * getpagesize();
for (i = 0; i < n; i++) {
buffer = (char *)malloc(size);
memset(buffer, 0xff, size);
madvise(buffer, size, MADV_MERGEABLE);
if (ret < 0) {
fprintf(stderr, "malloc madvise failed: ret:
%d, reason: %s\n", ret, strerror(errno));
}
usleep(500);
}
printf("Donepress ^C\n");
pause();
return 0;
}
Note: madvise() system call is not failing here, as mentioned earlier.
I guess the page is aligned with getpagesize().
Then I do this to invoke ksm:
# echo 1 > /sys/kernel/mm/ksm/run
# ./malloc-test.out &
# sleep 5
# echo 0 > /sys/kernel/mm/ksm/run
#

Also, the anon pages in the system shows like this:
BEFORE:
-
~ # cat /proc/meminfo | grep -i anon
Active(anon):  40740 kB
Inactive(anon):0 kB
AnonPages: 40760 kB
AnonHugePages: 0 kB

AFTER MERGING:
--
~ # cat /proc/meminfo | grep -i anon
Active(anon):440 kB
Inactive(anon):0 kB
AnonPages:   188 kB
AnonHugePages: 0 kB

I want to understand the KSM output w.r.t to the above program, and
cross-check if the output is correct.
Can someone help me to understand it?

As of now, what I understood is that:
- I am allocating around 400KB of memory 100 times. That is: 100 * 100
* 4K = 1 pages (which are all with similar content).
- Output says: 10097 page_sharing happened.
- Pages currently shared is: 3
- So total pages are: 10097 + 3 = 10100

I could not understand from where the additional 100 pages came from?
Also, why some pages are shown as: pages_unshared ?
What can I interpret from this?
And, what does it mean by: pages_volatile:1 ?

Basically, I wanted to understand, is there any problem with the above
output, or it is fine.
If it is fine, how to prove it?



Thanks,
Pintu

On Mon, Sep 17, 2018 at 8:29 PM Mike Rapoport  wrote:
>
> On Mon, Sep 17, 2018 at 05:25:27PM +0530, Pintu Kumar wrote:
> > On Mon, Sep 17, 2018 at 11:46 AM Pintu Kumar  wrote:
> > > > > But still no effect.
> > > > > And I checked LTP test cases. It almost doing the same thing.
> > > > >
> > > > > I observed that [ksmd] thread is not waking up at all.
> > > > > I gave some print inside it, but I could never saw that prints coming.
> > > > > I could not find it running either in top command during the 
> > > > > operation.
> > > > > Is there anything needs to be done, to wakw up ksmd?
> > > > > I already set: echo 1 > /sys/kernel/mm/ksm.
> > > >
> > > > It should be echo 1 > /sys/kernel/mm/ksm/run
> > > >
> > >
> > > Oh yes, sorry for the typo.
> > > I tried the same, but still ksm is not getting invoked.
> > > Could someone confirm if KSM was working in 4.9 kernel?
> > >
> >
> > Ok, it's working now. I have to explicitly stop the ksm thread to see
> > the statistics.
> > Also there was some internal patch that was setting vm_flags to
> > VM_MERGABLE thus causing ksm_advise call to return.
> >
> > # echo 1 > /sys/kernel/mm/ksm/run
> > # ./malloc-test.out &
> > # echo 0 > /sys/kernel/mm/ksm/run
> >
> > ~ # grep -H '' /sys/kernel/mm/ksm/*
> > /sys/kernel/mm/ksm/full_scans:105
> > /sys/kernel/mm/ksm/pages_shared:1
> > /sys/kernel/mm/ksm/pages_sharing:999
> > /sys/kernel/mm/ksm/pages_to_scan:100
> > /sys/kernel/mm/ksm/pages_unshared:0
> > /sys/kernel/mm/ksm/pages_volatile:0
> > /sys/kernel/mm/ksm/run:0
> > /sys/kernel/mm/ksm/sleep_millisecs:20
> >
> >
> > However, I have one doubt.
> > Is the above data correct, for the below program?
>
> You have 1 shared page and 999

Re: KSM not working in 4.9 Kernel

[Pintu Kumar]

On Mon, Sep 17, 2018 at 11:46 AM Pintu Kumar  wrote:
> > > But still no effect.
> > > And I checked LTP test cases. It almost doing the same thing.
> > >
> > > I observed that [ksmd] thread is not waking up at all.
> > > I gave some print inside it, but I could never saw that prints coming.
> > > I could not find it running either in top command during the operation.
> > > Is there anything needs to be done, to wakw up ksmd?
> > > I already set: echo 1 > /sys/kernel/mm/ksm.
> >
> > It should be echo 1 > /sys/kernel/mm/ksm/run
> >
>
> Oh yes, sorry for the typo.
> I tried the same, but still ksm is not getting invoked.
> Could someone confirm if KSM was working in 4.9 kernel?
>

Ok, it's working now. I have to explicitly stop the ksm thread to see
the statistics.
Also there was some internal patch that was setting vm_flags to
VM_MERGABLE thus causing ksm_advise call to return.

# echo 1 > /sys/kernel/mm/ksm/run
# ./malloc-test.out &
# echo 0 > /sys/kernel/mm/ksm/run

~ # grep -H '' /sys/kernel/mm/ksm/*
/sys/kernel/mm/ksm/full_scans:105
/sys/kernel/mm/ksm/pages_shared:1
/sys/kernel/mm/ksm/pages_sharing:999
/sys/kernel/mm/ksm/pages_to_scan:100
/sys/kernel/mm/ksm/pages_unshared:0
/sys/kernel/mm/ksm/pages_volatile:0
/sys/kernel/mm/ksm/run:0
/sys/kernel/mm/ksm/sleep_millisecs:20


However, I have one doubt.
Is the above data correct, for the below program?

int main(int argc, char *argv[])
{
int i, n, size, ret;
char *buffer;
void *addr;

n = 10;
size = 100 * getpagesize();
for (i = 0; i < n; i++) {
buffer = (char *)malloc(size);
memset(buffer, 0xff, size);
madvise(buffer, size, MADV_MERGEABLE);
addr =  mmap(NULL, size,
   PROT_READ | PROT_EXEC | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS,
   -1, 0);
memset(addr, 0xff, size);
ret = madvise(addr, size, MADV_MERGEABLE);
if (ret < 0) {
fprintf(stderr, "madvise failed: ret: %d,
reason: %s\n", ret, strerror(errno));
    }
usleep(500);
}
printf("Donepress ^C\n");

pause();

return 0;
}


Thanks,
Pintu

Re: KSM not working in 4.9 Kernel

[Pintu Kumar]

On Mon, Sep 17, 2018 at 11:46 AM Pintu Kumar  wrote:
> > > But still no effect.
> > > And I checked LTP test cases. It almost doing the same thing.
> > >
> > > I observed that [ksmd] thread is not waking up at all.
> > > I gave some print inside it, but I could never saw that prints coming.
> > > I could not find it running either in top command during the operation.
> > > Is there anything needs to be done, to wakw up ksmd?
> > > I already set: echo 1 > /sys/kernel/mm/ksm.
> >
> > It should be echo 1 > /sys/kernel/mm/ksm/run
> >
>
> Oh yes, sorry for the typo.
> I tried the same, but still ksm is not getting invoked.
> Could someone confirm if KSM was working in 4.9 kernel?
>

Ok, it's working now. I have to explicitly stop the ksm thread to see
the statistics.
Also there was some internal patch that was setting vm_flags to
VM_MERGABLE thus causing ksm_advise call to return.

# echo 1 > /sys/kernel/mm/ksm/run
# ./malloc-test.out &
# echo 0 > /sys/kernel/mm/ksm/run

~ # grep -H '' /sys/kernel/mm/ksm/*
/sys/kernel/mm/ksm/full_scans:105
/sys/kernel/mm/ksm/pages_shared:1
/sys/kernel/mm/ksm/pages_sharing:999
/sys/kernel/mm/ksm/pages_to_scan:100
/sys/kernel/mm/ksm/pages_unshared:0
/sys/kernel/mm/ksm/pages_volatile:0
/sys/kernel/mm/ksm/run:0
/sys/kernel/mm/ksm/sleep_millisecs:20


However, I have one doubt.
Is the above data correct, for the below program?

int main(int argc, char *argv[])
{
int i, n, size, ret;
char *buffer;
void *addr;

n = 10;
size = 100 * getpagesize();
for (i = 0; i < n; i++) {
buffer = (char *)malloc(size);
memset(buffer, 0xff, size);
madvise(buffer, size, MADV_MERGEABLE);
addr =  mmap(NULL, size,
   PROT_READ | PROT_EXEC | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS,
   -1, 0);
memset(addr, 0xff, size);
ret = madvise(addr, size, MADV_MERGEABLE);
if (ret < 0) {
fprintf(stderr, "madvise failed: ret: %d,
reason: %s\n", ret, strerror(errno));
    }
usleep(500);
}
printf("Donepress ^C\n");

pause();

return 0;
}


Thanks,
Pintu

Re: KSM not working in 4.9 Kernel

[Pintu Kumar]

On Mon, Sep 17, 2018 at 10:07 AM Mike Rapoport  wrote:
>
> On Sun, Sep 16, 2018 at 10:35:17PM +0530, Pintu Kumar wrote:
> > On Sun, Sep 16, 2018 at 9:02 PM Mike Rapoport  
> > wrote:
> > >
> > > On Fri, Sep 14, 2018 at 07:58:01PM +0530, Pintu Kumar wrote:
> > > > Hi All,
> > > >
> > > > Board: Hikey620 ARM64
> > > > Kernel: 4.9.20
> > > >
> > > > I am trying to verify KSM (Kernel Same Page Merging) functionality on
> > > > 4.9 Kernel using "mmap" and madvise user space test utility.
> > > > But to my observation, it seems KSM is not working for me.
> > > > CONFIG_KSM=y is enabled in kernel.
> > > > ksm_init is also called during boot up.
> > > >   443 ?SN 0:00 [ksmd]
> > > >
> > > > ksmd thread is also running.
> > > >
> > > > However, when I see the sysfs, no values are written.
> > > > ~ # grep -H '' /sys/kernel/mm/ksm/*
> > > > /sys/kernel/mm/ksm/pages_hashed:0
> > > > /sys/kernel/mm/ksm/pages_scanned:0
> > > > /sys/kernel/mm/ksm/pages_shared:0
> > > > /sys/kernel/mm/ksm/pages_sharing:0
> > > > /sys/kernel/mm/ksm/pages_to_scan:200
> > > > /sys/kernel/mm/ksm/pages_unshared:0
> > > > /sys/kernel/mm/ksm/pages_volatile:0
> > > > /sys/kernel/mm/ksm/run:1
> > > > /sys/kernel/mm/ksm/sleep_millisecs:1000
> > > >
> > > > So, please let me know if I am doing any thing wrong.
> > > >
> > > > This is the test utility:
> > > > int main(int argc, char *argv[])
> > > > {
> > > > int i, n, size;
> > > > char *buffer;
> > > > void *addr;
> > > >
> > > > n = 100;
> > > > size = 100 * getpagesize();
> > > > for (i = 0; i < n; i++) {
> > > > buffer = (char *)malloc(size);
> > > > memset(buffer, 0xff, size);
> > > > addr =  mmap(NULL, size,
> > > >PROT_READ | PROT_EXEC | PROT_WRITE,
> > > > MAP_PRIVATE | MAP_ANONYMOUS,
> > > >-1, 0);
> > > > madvise(addr, size, MADV_MERGEABLE);
> > >
> > > Just mmap'ing an area does not allocate any physical pages, so KSM has
> > > nothing to merge.
> > >
> > > You need to memset(addr,...) after mmap().
> > >
> >
> > Yes, I am doing memset also.
> > memset(addr, 0xff, size);
> >
> > But still no effect.
> > And I checked LTP test cases. It almost doing the same thing.
> >
> > I observed that [ksmd] thread is not waking up at all.
> > I gave some print inside it, but I could never saw that prints coming.
> > I could not find it running either in top command during the operation.
> > Is there anything needs to be done, to wakw up ksmd?
> > I already set: echo 1 > /sys/kernel/mm/ksm.
>
> It should be echo 1 > /sys/kernel/mm/ksm/run
>

Oh yes, sorry for the typo.
I tried the same, but still ksm is not getting invoked.
Could someone confirm if KSM was working in 4.9 kernel?


> >
> >
> > > > sleep(1);
> > > > }
> > > > printf("Donepress ^C\n");
> > > >
> > > > pause();
> > > >
> > > > return 0;
> > > > }
> > > >
> > > >
> > > >
> > > > Thanks,
> > > > Pintu
> > > >
> > >
> > > --
> > > Sincerely yours,
> > > Mike.
> > >
> >
>
> --
> Sincerely yours,
> Mike.
>

Re: KSM not working in 4.9 Kernel

[Pintu Kumar]

On Mon, Sep 17, 2018 at 10:07 AM Mike Rapoport  wrote:
>
> On Sun, Sep 16, 2018 at 10:35:17PM +0530, Pintu Kumar wrote:
> > On Sun, Sep 16, 2018 at 9:02 PM Mike Rapoport  
> > wrote:
> > >
> > > On Fri, Sep 14, 2018 at 07:58:01PM +0530, Pintu Kumar wrote:
> > > > Hi All,
> > > >
> > > > Board: Hikey620 ARM64
> > > > Kernel: 4.9.20
> > > >
> > > > I am trying to verify KSM (Kernel Same Page Merging) functionality on
> > > > 4.9 Kernel using "mmap" and madvise user space test utility.
> > > > But to my observation, it seems KSM is not working for me.
> > > > CONFIG_KSM=y is enabled in kernel.
> > > > ksm_init is also called during boot up.
> > > >   443 ?SN 0:00 [ksmd]
> > > >
> > > > ksmd thread is also running.
> > > >
> > > > However, when I see the sysfs, no values are written.
> > > > ~ # grep -H '' /sys/kernel/mm/ksm/*
> > > > /sys/kernel/mm/ksm/pages_hashed:0
> > > > /sys/kernel/mm/ksm/pages_scanned:0
> > > > /sys/kernel/mm/ksm/pages_shared:0
> > > > /sys/kernel/mm/ksm/pages_sharing:0
> > > > /sys/kernel/mm/ksm/pages_to_scan:200
> > > > /sys/kernel/mm/ksm/pages_unshared:0
> > > > /sys/kernel/mm/ksm/pages_volatile:0
> > > > /sys/kernel/mm/ksm/run:1
> > > > /sys/kernel/mm/ksm/sleep_millisecs:1000
> > > >
> > > > So, please let me know if I am doing any thing wrong.
> > > >
> > > > This is the test utility:
> > > > int main(int argc, char *argv[])
> > > > {
> > > > int i, n, size;
> > > > char *buffer;
> > > > void *addr;
> > > >
> > > > n = 100;
> > > > size = 100 * getpagesize();
> > > > for (i = 0; i < n; i++) {
> > > > buffer = (char *)malloc(size);
> > > > memset(buffer, 0xff, size);
> > > > addr =  mmap(NULL, size,
> > > >PROT_READ | PROT_EXEC | PROT_WRITE,
> > > > MAP_PRIVATE | MAP_ANONYMOUS,
> > > >-1, 0);
> > > > madvise(addr, size, MADV_MERGEABLE);
> > >
> > > Just mmap'ing an area does not allocate any physical pages, so KSM has
> > > nothing to merge.
> > >
> > > You need to memset(addr,...) after mmap().
> > >
> >
> > Yes, I am doing memset also.
> > memset(addr, 0xff, size);
> >
> > But still no effect.
> > And I checked LTP test cases. It almost doing the same thing.
> >
> > I observed that [ksmd] thread is not waking up at all.
> > I gave some print inside it, but I could never saw that prints coming.
> > I could not find it running either in top command during the operation.
> > Is there anything needs to be done, to wakw up ksmd?
> > I already set: echo 1 > /sys/kernel/mm/ksm.
>
> It should be echo 1 > /sys/kernel/mm/ksm/run
>

Oh yes, sorry for the typo.
I tried the same, but still ksm is not getting invoked.
Could someone confirm if KSM was working in 4.9 kernel?


> >
> >
> > > > sleep(1);
> > > > }
> > > > printf("Donepress ^C\n");
> > > >
> > > > pause();
> > > >
> > > > return 0;
> > > > }
> > > >
> > > >
> > > >
> > > > Thanks,
> > > > Pintu
> > > >
> > >
> > > --
> > > Sincerely yours,
> > > Mike.
> > >
> >
>
> --
> Sincerely yours,
> Mike.
>

Re: KSM not working in 4.9 Kernel

[Pintu Kumar]

On Sun, Sep 16, 2018 at 9:02 PM Mike Rapoport  wrote:
>
> On Fri, Sep 14, 2018 at 07:58:01PM +0530, Pintu Kumar wrote:
> > Hi All,
> >
> > Board: Hikey620 ARM64
> > Kernel: 4.9.20
> >
> > I am trying to verify KSM (Kernel Same Page Merging) functionality on
> > 4.9 Kernel using "mmap" and madvise user space test utility.
> > But to my observation, it seems KSM is not working for me.
> > CONFIG_KSM=y is enabled in kernel.
> > ksm_init is also called during boot up.
> >   443 ?SN 0:00 [ksmd]
> >
> > ksmd thread is also running.
> >
> > However, when I see the sysfs, no values are written.
> > ~ # grep -H '' /sys/kernel/mm/ksm/*
> > /sys/kernel/mm/ksm/pages_hashed:0
> > /sys/kernel/mm/ksm/pages_scanned:0
> > /sys/kernel/mm/ksm/pages_shared:0
> > /sys/kernel/mm/ksm/pages_sharing:0
> > /sys/kernel/mm/ksm/pages_to_scan:200
> > /sys/kernel/mm/ksm/pages_unshared:0
> > /sys/kernel/mm/ksm/pages_volatile:0
> > /sys/kernel/mm/ksm/run:1
> > /sys/kernel/mm/ksm/sleep_millisecs:1000
> >
> > So, please let me know if I am doing any thing wrong.
> >
> > This is the test utility:
> > int main(int argc, char *argv[])
> > {
> > int i, n, size;
> > char *buffer;
> > void *addr;
> >
> > n = 100;
> > size = 100 * getpagesize();
> > for (i = 0; i < n; i++) {
> > buffer = (char *)malloc(size);
> > memset(buffer, 0xff, size);
> > addr =  mmap(NULL, size,
> >PROT_READ | PROT_EXEC | PROT_WRITE,
> > MAP_PRIVATE | MAP_ANONYMOUS,
> >-1, 0);
> > madvise(addr, size, MADV_MERGEABLE);
>
> Just mmap'ing an area does not allocate any physical pages, so KSM has
> nothing to merge.
>
> You need to memset(addr,...) after mmap().
>

Yes, I am doing memset also.
memset(addr, 0xff, size);

But still no effect.
And I checked LTP test cases. It almost doing the same thing.

I observed that [ksmd] thread is not waking up at all.
I gave some print inside it, but I could never saw that prints coming.
I could not find it running either in top command during the operation.
Is there anything needs to be done, to wakw up ksmd?
I already set: echo 1 > /sys/kernel/mm/ksm.



> > sleep(1);
> > }
> > printf("Donepress ^C\n");
> >
> > pause();
> >
> > return 0;
> > }
> >
> >
> >
> > Thanks,
> > Pintu
> >
>
> --
> Sincerely yours,
> Mike.
>

Re: KSM not working in 4.9 Kernel

[Pintu Kumar]

On Sun, Sep 16, 2018 at 9:02 PM Mike Rapoport  wrote:
>
> On Fri, Sep 14, 2018 at 07:58:01PM +0530, Pintu Kumar wrote:
> > Hi All,
> >
> > Board: Hikey620 ARM64
> > Kernel: 4.9.20
> >
> > I am trying to verify KSM (Kernel Same Page Merging) functionality on
> > 4.9 Kernel using "mmap" and madvise user space test utility.
> > But to my observation, it seems KSM is not working for me.
> > CONFIG_KSM=y is enabled in kernel.
> > ksm_init is also called during boot up.
> >   443 ?SN 0:00 [ksmd]
> >
> > ksmd thread is also running.
> >
> > However, when I see the sysfs, no values are written.
> > ~ # grep -H '' /sys/kernel/mm/ksm/*
> > /sys/kernel/mm/ksm/pages_hashed:0
> > /sys/kernel/mm/ksm/pages_scanned:0
> > /sys/kernel/mm/ksm/pages_shared:0
> > /sys/kernel/mm/ksm/pages_sharing:0
> > /sys/kernel/mm/ksm/pages_to_scan:200
> > /sys/kernel/mm/ksm/pages_unshared:0
> > /sys/kernel/mm/ksm/pages_volatile:0
> > /sys/kernel/mm/ksm/run:1
> > /sys/kernel/mm/ksm/sleep_millisecs:1000
> >
> > So, please let me know if I am doing any thing wrong.
> >
> > This is the test utility:
> > int main(int argc, char *argv[])
> > {
> > int i, n, size;
> > char *buffer;
> > void *addr;
> >
> > n = 100;
> > size = 100 * getpagesize();
> > for (i = 0; i < n; i++) {
> > buffer = (char *)malloc(size);
> > memset(buffer, 0xff, size);
> > addr =  mmap(NULL, size,
> >PROT_READ | PROT_EXEC | PROT_WRITE,
> > MAP_PRIVATE | MAP_ANONYMOUS,
> >-1, 0);
> > madvise(addr, size, MADV_MERGEABLE);
>
> Just mmap'ing an area does not allocate any physical pages, so KSM has
> nothing to merge.
>
> You need to memset(addr,...) after mmap().
>

Yes, I am doing memset also.
memset(addr, 0xff, size);

But still no effect.
And I checked LTP test cases. It almost doing the same thing.

I observed that [ksmd] thread is not waking up at all.
I gave some print inside it, but I could never saw that prints coming.
I could not find it running either in top command during the operation.
Is there anything needs to be done, to wakw up ksmd?
I already set: echo 1 > /sys/kernel/mm/ksm.



> > sleep(1);
> > }
> > printf("Donepress ^C\n");
> >
> > pause();
> >
> > return 0;
> > }
> >
> >
> >
> > Thanks,
> > Pintu
> >
>
> --
> Sincerely yours,
> Mike.
>

Re: KSM not working in 4.9 Kernel

[Pintu Kumar]

On Fri, 14 Sep 2018, 10:42 pm Yang Shi,  wrote:
>
> Hi Pintu,
>
> I recall there are some ksm test cases in LTP. Did you try them out?

No. I haven't seen the LTP test. I will check out now.
But I wonder what is the problem with my test?


> On Fri, Sep 14, 2018 at 7:28 AM Pintu Kumar  wrote:
> >
> > Hi All,
> >
> > Board: Hikey620 ARM64
> > Kernel: 4.9.20
> >
> > I am trying to verify KSM (Kernel Same Page Merging) functionality on
> > 4.9 Kernel using "mmap" and madvise user space test utility.
> > But to my observation, it seems KSM is not working for me.
> > CONFIG_KSM=y is enabled in kernel.
> > ksm_init is also called during boot up.
> >   443 ?SN 0:00 [ksmd]
> >
> > ksmd thread is also running.
> >
> > However, when I see the sysfs, no values are written.
> > ~ # grep -H '' /sys/kernel/mm/ksm/*
> > /sys/kernel/mm/ksm/pages_hashed:0
> > /sys/kernel/mm/ksm/pages_scanned:0
> > /sys/kernel/mm/ksm/pages_shared:0
> > /sys/kernel/mm/ksm/pages_sharing:0
> > /sys/kernel/mm/ksm/pages_to_scan:200
> > /sys/kernel/mm/ksm/pages_unshared:0
> > /sys/kernel/mm/ksm/pages_volatile:0
> > /sys/kernel/mm/ksm/run:1
> > /sys/kernel/mm/ksm/sleep_millisecs:1000
> >
> > So, please let me know if I am doing any thing wrong.
> >
> > This is the test utility:
> > int main(int argc, char *argv[])
> > {
> > int i, n, size;
> > char *buffer;
> > void *addr;
> >
> > n = 100;
> > size = 100 * getpagesize();
> > for (i = 0; i < n; i++) {
> > buffer = (char *)malloc(size);
> > memset(buffer, 0xff, size);
> > addr =  mmap(NULL, size,
> >PROT_READ | PROT_EXEC | PROT_WRITE,
> > MAP_PRIVATE | MAP_ANONYMOUS,
> >-1, 0);
> > madvise(addr, size, MADV_MERGEABLE);
> > sleep(1);
> > }
> > printf("Donepress ^C\n");
> >
> > pause();
> >
> > return 0;
> > }
> >
> >
> >
> > Thanks,
> > Pintu
> >

Re: KSM not working in 4.9 Kernel

[Pintu Kumar]

On Fri, 14 Sep 2018, 10:42 pm Yang Shi,  wrote:
>
> Hi Pintu,
>
> I recall there are some ksm test cases in LTP. Did you try them out?

No. I haven't seen the LTP test. I will check out now.
But I wonder what is the problem with my test?


> On Fri, Sep 14, 2018 at 7:28 AM Pintu Kumar  wrote:
> >
> > Hi All,
> >
> > Board: Hikey620 ARM64
> > Kernel: 4.9.20
> >
> > I am trying to verify KSM (Kernel Same Page Merging) functionality on
> > 4.9 Kernel using "mmap" and madvise user space test utility.
> > But to my observation, it seems KSM is not working for me.
> > CONFIG_KSM=y is enabled in kernel.
> > ksm_init is also called during boot up.
> >   443 ?SN 0:00 [ksmd]
> >
> > ksmd thread is also running.
> >
> > However, when I see the sysfs, no values are written.
> > ~ # grep -H '' /sys/kernel/mm/ksm/*
> > /sys/kernel/mm/ksm/pages_hashed:0
> > /sys/kernel/mm/ksm/pages_scanned:0
> > /sys/kernel/mm/ksm/pages_shared:0
> > /sys/kernel/mm/ksm/pages_sharing:0
> > /sys/kernel/mm/ksm/pages_to_scan:200
> > /sys/kernel/mm/ksm/pages_unshared:0
> > /sys/kernel/mm/ksm/pages_volatile:0
> > /sys/kernel/mm/ksm/run:1
> > /sys/kernel/mm/ksm/sleep_millisecs:1000
> >
> > So, please let me know if I am doing any thing wrong.
> >
> > This is the test utility:
> > int main(int argc, char *argv[])
> > {
> > int i, n, size;
> > char *buffer;
> > void *addr;
> >
> > n = 100;
> > size = 100 * getpagesize();
> > for (i = 0; i < n; i++) {
> > buffer = (char *)malloc(size);
> > memset(buffer, 0xff, size);
> > addr =  mmap(NULL, size,
> >PROT_READ | PROT_EXEC | PROT_WRITE,
> > MAP_PRIVATE | MAP_ANONYMOUS,
> >-1, 0);
> > madvise(addr, size, MADV_MERGEABLE);
> > sleep(1);
> > }
> > printf("Donepress ^C\n");
> >
> > pause();
> >
> > return 0;
> > }
> >
> >
> >
> > Thanks,
> > Pintu
> >

KSM not working in 4.9 Kernel

[Pintu Kumar]

Hi All,

Board: Hikey620 ARM64
Kernel: 4.9.20

I am trying to verify KSM (Kernel Same Page Merging) functionality on
4.9 Kernel using "mmap" and madvise user space test utility.
But to my observation, it seems KSM is not working for me.
CONFIG_KSM=y is enabled in kernel.
ksm_init is also called during boot up.
  443 ?SN 0:00 [ksmd]

ksmd thread is also running.

However, when I see the sysfs, no values are written.
~ # grep -H '' /sys/kernel/mm/ksm/*
/sys/kernel/mm/ksm/pages_hashed:0
/sys/kernel/mm/ksm/pages_scanned:0
/sys/kernel/mm/ksm/pages_shared:0
/sys/kernel/mm/ksm/pages_sharing:0
/sys/kernel/mm/ksm/pages_to_scan:200
/sys/kernel/mm/ksm/pages_unshared:0
/sys/kernel/mm/ksm/pages_volatile:0
/sys/kernel/mm/ksm/run:1
/sys/kernel/mm/ksm/sleep_millisecs:1000

So, please let me know if I am doing any thing wrong.

This is the test utility:
int main(int argc, char *argv[])
{
int i, n, size;
char *buffer;
void *addr;

n = 100;
size = 100 * getpagesize();
for (i = 0; i < n; i++) {
buffer = (char *)malloc(size);
memset(buffer, 0xff, size);
addr =  mmap(NULL, size,
   PROT_READ | PROT_EXEC | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS,
   -1, 0);
madvise(addr, size, MADV_MERGEABLE);
sleep(1);
}
printf("Donepress ^C\n");

pause();

return 0;
}



Thanks,
Pintu

KSM not working in 4.9 Kernel

[Pintu Kumar]

Hi All,

Board: Hikey620 ARM64
Kernel: 4.9.20

I am trying to verify KSM (Kernel Same Page Merging) functionality on
4.9 Kernel using "mmap" and madvise user space test utility.
But to my observation, it seems KSM is not working for me.
CONFIG_KSM=y is enabled in kernel.
ksm_init is also called during boot up.
  443 ?SN 0:00 [ksmd]

ksmd thread is also running.

However, when I see the sysfs, no values are written.
~ # grep -H '' /sys/kernel/mm/ksm/*
/sys/kernel/mm/ksm/pages_hashed:0
/sys/kernel/mm/ksm/pages_scanned:0
/sys/kernel/mm/ksm/pages_shared:0
/sys/kernel/mm/ksm/pages_sharing:0
/sys/kernel/mm/ksm/pages_to_scan:200
/sys/kernel/mm/ksm/pages_unshared:0
/sys/kernel/mm/ksm/pages_volatile:0
/sys/kernel/mm/ksm/run:1
/sys/kernel/mm/ksm/sleep_millisecs:1000

So, please let me know if I am doing any thing wrong.

This is the test utility:
int main(int argc, char *argv[])
{
int i, n, size;
char *buffer;
void *addr;

n = 100;
size = 100 * getpagesize();
for (i = 0; i < n; i++) {
buffer = (char *)malloc(size);
memset(buffer, 0xff, size);
addr =  mmap(NULL, size,
   PROT_READ | PROT_EXEC | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS,
   -1, 0);
madvise(addr, size, MADV_MERGEABLE);
sleep(1);
}
printf("Donepress ^C\n");

pause();

return 0;
}



Thanks,
Pintu

Re: [PREEMPT_RT]: Using printk-rt-aware.patch in non-rt kernel

[Pintu Kumar]

On Thu, Jul 26, 2018 at 9:08 PM Sebastian Andrzej Siewior
 wrote:
>
> On 2018-07-18 20:19:15 [+0530], Pintu Kumar wrote:
> > Hi All,
> Hi,
>
> > I have a question about PREEMPT_RT patch for 3.10 kernel.
> > I am trying to port this rt patch: 0224-printk-rt-aware.patch.patch
> > (see the patch below), in non-rt kernel.
> > I could able to successfully apply this patch after replacing:
> > migrate_enable/disable with preempt_enable/disable.
> > Things were working fine so far.
>
> Why?
>
> > Then, I noticed that "printk" from interrupt context is not appearing
> > on console (minicom), if console shell is active.
> > However, it appears on the dmesg output.
> >
> > So, I am wondering, what could be the cause of this patch for this
> > behavior in non-rt kernel?
> > Is this the expected behavior, even on PREEMPT_RT kernel?
>
> I *think* it is but there are hardly any prints from atomic context for
> anyone to notice. And the next print from non-atomic context should
> flush it out.
>
Yes, we observed the same behavior with CONFIG_PREEMPT_RT_FULL with
beagle bone-rt kernel 4.9.
And yes, after doing : echo "1234" > /dev/kmsg the content were flushed.
So, I guess this is the expected behavior with this patch.

> > Is there a way we can fix this issue on non-rt kernel?
> I would guess that a wakeup to klogd would fix it.
>
Sorry, can you elaborate more about "wakeup to klogd".
I wanted to try it and check.

> > Please help us with your suggestions.
> >
> > Thanks,
> > Pintu
>
> Sebastian

Re: [PREEMPT_RT]: Using printk-rt-aware.patch in non-rt kernel

[Pintu Kumar]

On Thu, Jul 26, 2018 at 9:08 PM Sebastian Andrzej Siewior
 wrote:
>
> On 2018-07-18 20:19:15 [+0530], Pintu Kumar wrote:
> > Hi All,
> Hi,
>
> > I have a question about PREEMPT_RT patch for 3.10 kernel.
> > I am trying to port this rt patch: 0224-printk-rt-aware.patch.patch
> > (see the patch below), in non-rt kernel.
> > I could able to successfully apply this patch after replacing:
> > migrate_enable/disable with preempt_enable/disable.
> > Things were working fine so far.
>
> Why?
>
> > Then, I noticed that "printk" from interrupt context is not appearing
> > on console (minicom), if console shell is active.
> > However, it appears on the dmesg output.
> >
> > So, I am wondering, what could be the cause of this patch for this
> > behavior in non-rt kernel?
> > Is this the expected behavior, even on PREEMPT_RT kernel?
>
> I *think* it is but there are hardly any prints from atomic context for
> anyone to notice. And the next print from non-atomic context should
> flush it out.
>
Yes, we observed the same behavior with CONFIG_PREEMPT_RT_FULL with
beagle bone-rt kernel 4.9.
And yes, after doing : echo "1234" > /dev/kmsg the content were flushed.
So, I guess this is the expected behavior with this patch.

> > Is there a way we can fix this issue on non-rt kernel?
> I would guess that a wakeup to klogd would fix it.
>
Sorry, can you elaborate more about "wakeup to klogd".
I wanted to try it and check.

> > Please help us with your suggestions.
> >
> > Thanks,
> > Pintu
>
> Sebastian

Re: [PREEMPT_RT]: Using printk-rt-aware.patch in non-rt kernel

[Pintu Kumar]

Hi All,

I have a question about PREEMPT_RT patch for 3.10 kernel.
I am trying to port this rt patch: 0224-printk-rt-aware.patch.patch
(see the patch below), in non-rt kernel.
I could able to successfully apply this patch after replacing:
migrate_enable/disable with preempt_enable/disable.
Things were working fine so far.

Then, I noticed that "printk" from interrupt context is not appearing
on console (minicom), if console shell is active.
However, it appears on the dmesg output.

So, I am wondering, what could be the cause of this patch for this
behavior in non-rt kernel?
Is this the expected behavior, even on PREEMPT_RT kernel?
Is there a way we can fix this issue on non-rt kernel?

Please help us with your suggestions.

Thanks,
Pintu

On Wed, Jun 13, 2018 at 8:02 PM Pintu Kumar  wrote:
>
> Dear Thomas,
>
> I was looking into this RT patches for 3.10 kernel:
> https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/3.10/patches-3.10.108-rt123.tar.gz
>
> And I came across your patch: 0224-printk-rt-aware.patch.patch
> I guess, this patch is related to improving irq latency during printk.
> And this patch can work only if PREEMPT_RT_FULL is enabled.
>
> But, I have 3.10 non-RT kernel, and still I want to use this feature
> for non-RT case and achieve the same functionality.
> Can you give me some idea, how to convert this RT patch to non-RT
> kernel and still achieve the same behavior.
> I know this is weird but it is our internal requirement.
>

> So, if you have any suggestions, it will be really helpful.
>
> Thank You!
>
> Regards,
> Pintu
>
> This is the patch details:
> ---
> rt-patches/patches$ cat 0224-printk-rt-aware.patch.patch
> From ec944721d45454681485906615affa9368e0dfae Mon Sep 17 00:00:00 2001
> From: Thomas Gleixner 
> Date: Wed, 19 Sep 2012 14:50:37 +0200
> Subject: [PATCH 224/405] printk-rt-aware.patch
>
> Signed-off-by: Thomas Gleixner 
> ---
>  kernel/printk.c | 34 +-
>  1 file changed, 29 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/printk.c b/kernel/printk.c
> index e879b8615a0f..07d32a2c8a5f 100644
> --- a/kernel/printk.c
> +++ b/kernel/printk.c
> @@ -1277,6 +1277,7 @@ static void call_console_drivers(int level,
> const char *text, size_t len)
> if (!console_drivers)
> return;
>
> +   migrate_disable();
> for_each_console(con) {
> if (exclusive_console && con != exclusive_console)
> continue;
> @@ -1289,6 +1290,7 @@ static void call_console_drivers(int level,
> const char *text, size_t len)
> continue;
> con->write(con, text, len);
> }
> +   migrate_enable();
>  }
>
>  /*
> @@ -1348,12 +1350,18 @@ static inline int can_use_console(unsigned int cpu)
>   * interrupts disabled. It should return with 'lockbuf_lock'
>   * released but interrupts still disabled.
>   */
> -static int console_trylock_for_printk(unsigned int cpu)
> +static int console_trylock_for_printk(unsigned int cpu, unsigned long flags)
> __releases(_lock)
>  {
> int retval = 0, wake = 0;
> +#ifdef CONFIG_PREEMPT_RT_FULL
> +   int lock = !early_boot_irqs_disabled && !irqs_disabled_flags(flags) &&
> +   (preempt_count() <= 1);
> +#else
> +   int lock = 1;
> +#endif
>
> -   if (console_trylock()) {
> +   if (lock && console_trylock()) {
> retval = 1;
>
> /*
> @@ -1688,8 +1696,15 @@ asmlinkage int vprintk_emit(int facility, int level,
>  * The console_trylock_for_printk() function will release 
> 'logbuf_lock'
>  * regardless of whether it actually gets the console semaphore or 
> not.
>  */
> -   if (console_trylock_for_printk(this_cpu))
> +   if (console_trylock_for_printk(this_cpu, flags)) {
> +#ifndef CONFIG_PREEMPT_RT_FULL
> console_unlock();
> +#else
> +   raw_local_irq_restore(flags);
> +   console_unlock();
> +   raw_local_irq_save(flags);
> +#endif
> +   }
>
> lockdep_on();
>  out_restore_irqs:
> @@ -2043,11 +2058,16 @@ static void console_cont_flush(char *text, size_t 
> size)
> goto out;
>
> len = cont_print_text(text, size);
> +#ifndef CONFIG_PREEMPT_RT_FULL
> raw_spin_unlock(_lock);
> stop_critical_timings();
> call_console_drivers(cont.level, text, len);
> start_critical_timings();
> local_irq_restore(flags);
> +#else
> +   raw_spin_unlock_irqrestore(_lock, flags);
>

Re: [PREEMPT_RT]: Using printk-rt-aware.patch in non-rt kernel

[Pintu Kumar]

Hi All,

I have a question about PREEMPT_RT patch for 3.10 kernel.
I am trying to port this rt patch: 0224-printk-rt-aware.patch.patch
(see the patch below), in non-rt kernel.
I could able to successfully apply this patch after replacing:
migrate_enable/disable with preempt_enable/disable.
Things were working fine so far.

Then, I noticed that "printk" from interrupt context is not appearing
on console (minicom), if console shell is active.
However, it appears on the dmesg output.

So, I am wondering, what could be the cause of this patch for this
behavior in non-rt kernel?
Is this the expected behavior, even on PREEMPT_RT kernel?
Is there a way we can fix this issue on non-rt kernel?

Please help us with your suggestions.

Thanks,
Pintu

On Wed, Jun 13, 2018 at 8:02 PM Pintu Kumar  wrote:
>
> Dear Thomas,
>
> I was looking into this RT patches for 3.10 kernel:
> https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/3.10/patches-3.10.108-rt123.tar.gz
>
> And I came across your patch: 0224-printk-rt-aware.patch.patch
> I guess, this patch is related to improving irq latency during printk.
> And this patch can work only if PREEMPT_RT_FULL is enabled.
>
> But, I have 3.10 non-RT kernel, and still I want to use this feature
> for non-RT case and achieve the same functionality.
> Can you give me some idea, how to convert this RT patch to non-RT
> kernel and still achieve the same behavior.
> I know this is weird but it is our internal requirement.
>

> So, if you have any suggestions, it will be really helpful.
>
> Thank You!
>
> Regards,
> Pintu
>
> This is the patch details:
> ---
> rt-patches/patches$ cat 0224-printk-rt-aware.patch.patch
> From ec944721d45454681485906615affa9368e0dfae Mon Sep 17 00:00:00 2001
> From: Thomas Gleixner 
> Date: Wed, 19 Sep 2012 14:50:37 +0200
> Subject: [PATCH 224/405] printk-rt-aware.patch
>
> Signed-off-by: Thomas Gleixner 
> ---
>  kernel/printk.c | 34 +-
>  1 file changed, 29 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/printk.c b/kernel/printk.c
> index e879b8615a0f..07d32a2c8a5f 100644
> --- a/kernel/printk.c
> +++ b/kernel/printk.c
> @@ -1277,6 +1277,7 @@ static void call_console_drivers(int level,
> const char *text, size_t len)
> if (!console_drivers)
> return;
>
> +   migrate_disable();
> for_each_console(con) {
> if (exclusive_console && con != exclusive_console)
> continue;
> @@ -1289,6 +1290,7 @@ static void call_console_drivers(int level,
> const char *text, size_t len)
> continue;
> con->write(con, text, len);
> }
> +   migrate_enable();
>  }
>
>  /*
> @@ -1348,12 +1350,18 @@ static inline int can_use_console(unsigned int cpu)
>   * interrupts disabled. It should return with 'lockbuf_lock'
>   * released but interrupts still disabled.
>   */
> -static int console_trylock_for_printk(unsigned int cpu)
> +static int console_trylock_for_printk(unsigned int cpu, unsigned long flags)
> __releases(_lock)
>  {
> int retval = 0, wake = 0;
> +#ifdef CONFIG_PREEMPT_RT_FULL
> +   int lock = !early_boot_irqs_disabled && !irqs_disabled_flags(flags) &&
> +   (preempt_count() <= 1);
> +#else
> +   int lock = 1;
> +#endif
>
> -   if (console_trylock()) {
> +   if (lock && console_trylock()) {
> retval = 1;
>
> /*
> @@ -1688,8 +1696,15 @@ asmlinkage int vprintk_emit(int facility, int level,
>  * The console_trylock_for_printk() function will release 
> 'logbuf_lock'
>  * regardless of whether it actually gets the console semaphore or 
> not.
>  */
> -   if (console_trylock_for_printk(this_cpu))
> +   if (console_trylock_for_printk(this_cpu, flags)) {
> +#ifndef CONFIG_PREEMPT_RT_FULL
> console_unlock();
> +#else
> +   raw_local_irq_restore(flags);
> +   console_unlock();
> +   raw_local_irq_save(flags);
> +#endif
> +   }
>
> lockdep_on();
>  out_restore_irqs:
> @@ -2043,11 +2058,16 @@ static void console_cont_flush(char *text, size_t 
> size)
> goto out;
>
> len = cont_print_text(text, size);
> +#ifndef CONFIG_PREEMPT_RT_FULL
> raw_spin_unlock(_lock);
> stop_critical_timings();
> call_console_drivers(cont.level, text, len);
> start_critical_timings();
> local_irq_restore(flags);
> +#else
> +   raw_spin_unlock_irqrestore(_lock, flags);
>

Re: [PATCH 2/3] selftests/android: initialize heap_type to avoid compiling warning

[Pintu Kumar]

On Tue, Jul 10, 2018 at 8:20 PM Shuah Khan  wrote:
>
> Hi Li Zhijian,
>
> On 07/01/2018 09:53 PM, Li Zhijian wrote:
> > root@vm-lkp-nex04-8G-7 ~/linux-v4.18-rc2/tools/testing/selftests/android# 
> > make
> > make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
> > rule.
> > make[1]: Entering directory 
> > '/root/linux-v4.18-rc2/tools/testing/selftests/android/ion'
> > gcc  -I. -I../../../../../drivers/staging/android/uapi/ 
> > -I../../../../../usr/include/ -Wall -O2 -gionapp_export.c ipcsocket.c 
> > ionutils.c   -o ionapp_export
> > ionapp_export.c: In function 'main':
> > ionapp_export.c:91:2: warning: 'heap_type' may be used uninitialized in
> > this function [-Wmaybe-uninitialized]
> >   printf("heap_type: %ld, heap_size: %ld\n", heap_type, heap_size);
> >   ^~~~
> >
> > CC: Shuah Khan 
> > CC: Pintu Agarwal 
> > Signed-off-by: Li Zhijian 
> > ---
> >  tools/testing/selftests/android/ion/ionapp_export.c | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/tools/testing/selftests/android/ion/ionapp_export.c 
> > b/tools/testing/selftests/android/ion/ionapp_export.c
> > index a944e72..e3435c2 100644
> > --- a/tools/testing/selftests/android/ion/ionapp_export.c
> > +++ b/tools/testing/selftests/android/ion/ionapp_export.c
> > @@ -49,6 +49,7 @@ int main(int argc, char *argv[])
> >   return -1;
> >   }
> >
> > + heap_type = -1UL;
>
> Initialize it to one of the valid types. ION_HEAP_TYPE_SYSTEM
> is one choice.
>
Yes, the test requires at least one of the heap type.
If you want, you can set it to the default value (0) at the
initialization time and not -1.

>
> >   heap_size = 0;
> >   flags = 0;
> >
May be we can set the heap_type as 0 here, to avoid those
uninitialized warnings.

> > @@ -82,6 +83,12 @@ int main(int argc, char *argv[])
> >   }
> >   }
> >
> > + if (heap_type == -1UL) {
> > + printf("heap_type is invalid\n");
> > + print_usage(argc, argv);
> > + exit(1);
> > + }
>
> This check isn't necessary. The test requires two arguments,
> -i  and -s  and won't run without either
> one of them. heap_type is going to be ION_HEAP_TYPE_SYSTEM or
> ION_HEAP_TYPE_SYSTEM_CONTIG at this point.
>
> Interesting. Looks like this test doesn't cover all ion_heap_types.
>
Yes, all heap_types were not supported. As per Laura's request I removed it.
Other heap_types actually requires explicit declaration of reserved
memory or CMA region.

If you require other heap_type support then may be you can look into
my github version:
https://github.com/pintuk/LINUX/tree/master/android/ion


> thanks,
> -- Shuah

Re: [PATCH 2/3] selftests/android: initialize heap_type to avoid compiling warning

[Pintu Kumar]

On Tue, Jul 10, 2018 at 8:20 PM Shuah Khan  wrote:
>
> Hi Li Zhijian,
>
> On 07/01/2018 09:53 PM, Li Zhijian wrote:
> > root@vm-lkp-nex04-8G-7 ~/linux-v4.18-rc2/tools/testing/selftests/android# 
> > make
> > make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
> > rule.
> > make[1]: Entering directory 
> > '/root/linux-v4.18-rc2/tools/testing/selftests/android/ion'
> > gcc  -I. -I../../../../../drivers/staging/android/uapi/ 
> > -I../../../../../usr/include/ -Wall -O2 -gionapp_export.c ipcsocket.c 
> > ionutils.c   -o ionapp_export
> > ionapp_export.c: In function 'main':
> > ionapp_export.c:91:2: warning: 'heap_type' may be used uninitialized in
> > this function [-Wmaybe-uninitialized]
> >   printf("heap_type: %ld, heap_size: %ld\n", heap_type, heap_size);
> >   ^~~~
> >
> > CC: Shuah Khan 
> > CC: Pintu Agarwal 
> > Signed-off-by: Li Zhijian 
> > ---
> >  tools/testing/selftests/android/ion/ionapp_export.c | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/tools/testing/selftests/android/ion/ionapp_export.c 
> > b/tools/testing/selftests/android/ion/ionapp_export.c
> > index a944e72..e3435c2 100644
> > --- a/tools/testing/selftests/android/ion/ionapp_export.c
> > +++ b/tools/testing/selftests/android/ion/ionapp_export.c
> > @@ -49,6 +49,7 @@ int main(int argc, char *argv[])
> >   return -1;
> >   }
> >
> > + heap_type = -1UL;
>
> Initialize it to one of the valid types. ION_HEAP_TYPE_SYSTEM
> is one choice.
>
Yes, the test requires at least one of the heap type.
If you want, you can set it to the default value (0) at the
initialization time and not -1.

>
> >   heap_size = 0;
> >   flags = 0;
> >
May be we can set the heap_type as 0 here, to avoid those
uninitialized warnings.

> > @@ -82,6 +83,12 @@ int main(int argc, char *argv[])
> >   }
> >   }
> >
> > + if (heap_type == -1UL) {
> > + printf("heap_type is invalid\n");
> > + print_usage(argc, argv);
> > + exit(1);
> > + }
>
> This check isn't necessary. The test requires two arguments,
> -i  and -s  and won't run without either
> one of them. heap_type is going to be ION_HEAP_TYPE_SYSTEM or
> ION_HEAP_TYPE_SYSTEM_CONTIG at this point.
>
> Interesting. Looks like this test doesn't cover all ion_heap_types.
>
Yes, all heap_types were not supported. As per Laura's request I removed it.
Other heap_types actually requires explicit declaration of reserved
memory or CMA region.

If you require other heap_type support then may be you can look into
my github version:
https://github.com/pintuk/LINUX/tree/master/android/ion


> thanks,
> -- Shuah

Re: Delivery Status Notification (Failure)

[Pintu Kumar]

Dear Lucas,

Can you give me some pointers on how to set affinity for entire GPIO Bank.
Currently I am exploring drivers/gpio/gpio-mxc.c to find out how the
GPIO banks are set up.

I also found that affinity can be set using: desc->irq_data.affinity,
may be by using cpumask_copy(...).
But still I am not familiar with this.

So, I need your help.


Thank You!

Regards,
Pintu



On Thu, May 17, 2018 at 6:58 PM, Pintu Kumar <pintu.p...@gmail.com> wrote:
> On Mon, May 14, 2018 at 7:58 PM, Pintu Kumar <pintu.p...@gmail.com> wrote:
>>
>> On Mon, May 14, 2018 at 6:41 PM, Lucas Stach <l.st...@pengutronix.de> wrote:
>> > Am Montag, den 14.05.2018, 17:42 +0530 schrieb Pintu Kumar:
>> >> Hi,
>> >>
>> >> Is there any work around possible to set IRQ affinity for some GPIO
>> >> interrupt ?
>> >> How to avoid CPU0 to receive the current GPIO interrupt ?
>> >> How do we assign GPIO interrupts to any CPU other than CPU0 ?
>> >> Is it possible to isolate CPU0 for a sometime, from my GPIO driver so
>> >> that GPIO interrupt can be served by another CPU ?
>> >>
>> >> Need your inputs to decide whether it is still possible to set
>> >> affinity for GPIO interrupt, or its impossible ?
>> >
>> > This is not possible. The GPIO IRQs are aggregated into one GPC/GIC IRQ
>> > line per GPIO bank, so it is not possible to change affinity of a
>> > single GPIO interrupt to another CPU.
>>
>> OK. Thanks for your confirmation.
>>
>> > Best we could do is change the
>> > affinity of the whole bank,
>>
>
> Hi,
>
> I found that the driver is responsible for setting GPIO bank in i.MX7:
> https://elixir.bootlin.com/linux/v4.2/source/drivers/gpio/gpio-mxc.c
>
> However I still dont know how to set the cpumask for one of the GPIO Bank.
>
> From this link, it seems it is possible to set affinity for a GPIO IRQ.
> https://community.nxp.com/thread/303144
>
> But when I try it form my GPIO138 (GPIO5_IO10) it did not help.
>
> So, as you said, I wanted to change affinity for the whole GPIO bank and try 
> it.
> Please give me some pointers.
>
> Thanks
>
>
>> OK. How can we do this on the fly from my driver code.
>> If you have any reference please let me know.
>> This is required only for experimental purpose to prove the point to be mgmt.
>> My idea is, from the driver, change the affinity of the whole bank.
>> So, the GPIO interrupt can be delivered on to this specific CPU bank.
>> Once I am done, I will revert back to the old bank.
>> Please give me some hint on how to do this from my kernel module
>>
>>
>> > but given the limited usefulness of
>> > something like that, nobody bothered to implement such a thing.
>> >
>> > Regards,
>> > Lucas
>> >
>> >>
>> >>
>> >> On Fri, May 11, 2018 at 8:07 PM, Pintu Kumar <pintu.p...@gmail.com>
>> >> wrote:
>> >> > On Fri, May 11, 2018 at 6:34 PM, Lucas Stach <l.stach@pengutronix.d
>> >> > e> wrote:
>> >> > > Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King -
>> >> > > ARM Linux:
>> >> > > > On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
>> >> > > > > Hi,
>> >> > > > >
>> >> > > > > I need one help.
>> >> > > > > I am using i.MX7 Sabre board with kernel version 4.1.15
>> >> > > > >
>> >> > > > > Let's say I am interested in GPIO number: 21
>> >> > > > > I wanted to set CPU affinity for particular GPIO->IRQ number,
>> >> > > > > so I
>> >> > > > > tried the below steps:
>> >> > > > > root@10:~# echo 21 > /sys/class/gpio/export
>> >> > > > > root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
>> >> > > > > root@10:~# cat /proc/interrupts | grep 21
>> >> > > > >   47: 0 0 gpio-mxc 21 Edge gpiolib
>> >> > > > > root@10:~# cat /sys/class/gpio/gpio21/direction
>> >> > > > > in
>> >> > > > > root@10:~# cat /proc/irq/47/smp_affinity
>> >> > > > > 3
>> >> > > > > root@10:~# echo 2 > /proc/irq/47/smp_affinity
>> >> > > > > -bash: echo: write error: Input/output error
>> >> > > > >
>> >> > > > > But I g

Re: Delivery Status Notification (Failure)

[Pintu Kumar]

Dear Lucas,

Can you give me some pointers on how to set affinity for entire GPIO Bank.
Currently I am exploring drivers/gpio/gpio-mxc.c to find out how the
GPIO banks are set up.

I also found that affinity can be set using: desc->irq_data.affinity,
may be by using cpumask_copy(...).
But still I am not familiar with this.

So, I need your help.


Thank You!

Regards,
Pintu



On Thu, May 17, 2018 at 6:58 PM, Pintu Kumar  wrote:
> On Mon, May 14, 2018 at 7:58 PM, Pintu Kumar  wrote:
>>
>> On Mon, May 14, 2018 at 6:41 PM, Lucas Stach  wrote:
>> > Am Montag, den 14.05.2018, 17:42 +0530 schrieb Pintu Kumar:
>> >> Hi,
>> >>
>> >> Is there any work around possible to set IRQ affinity for some GPIO
>> >> interrupt ?
>> >> How to avoid CPU0 to receive the current GPIO interrupt ?
>> >> How do we assign GPIO interrupts to any CPU other than CPU0 ?
>> >> Is it possible to isolate CPU0 for a sometime, from my GPIO driver so
>> >> that GPIO interrupt can be served by another CPU ?
>> >>
>> >> Need your inputs to decide whether it is still possible to set
>> >> affinity for GPIO interrupt, or its impossible ?
>> >
>> > This is not possible. The GPIO IRQs are aggregated into one GPC/GIC IRQ
>> > line per GPIO bank, so it is not possible to change affinity of a
>> > single GPIO interrupt to another CPU.
>>
>> OK. Thanks for your confirmation.
>>
>> > Best we could do is change the
>> > affinity of the whole bank,
>>
>
> Hi,
>
> I found that the driver is responsible for setting GPIO bank in i.MX7:
> https://elixir.bootlin.com/linux/v4.2/source/drivers/gpio/gpio-mxc.c
>
> However I still dont know how to set the cpumask for one of the GPIO Bank.
>
> From this link, it seems it is possible to set affinity for a GPIO IRQ.
> https://community.nxp.com/thread/303144
>
> But when I try it form my GPIO138 (GPIO5_IO10) it did not help.
>
> So, as you said, I wanted to change affinity for the whole GPIO bank and try 
> it.
> Please give me some pointers.
>
> Thanks
>
>
>> OK. How can we do this on the fly from my driver code.
>> If you have any reference please let me know.
>> This is required only for experimental purpose to prove the point to be mgmt.
>> My idea is, from the driver, change the affinity of the whole bank.
>> So, the GPIO interrupt can be delivered on to this specific CPU bank.
>> Once I am done, I will revert back to the old bank.
>> Please give me some hint on how to do this from my kernel module
>>
>>
>> > but given the limited usefulness of
>> > something like that, nobody bothered to implement such a thing.
>> >
>> > Regards,
>> > Lucas
>> >
>> >>
>> >>
>> >> On Fri, May 11, 2018 at 8:07 PM, Pintu Kumar 
>> >> wrote:
>> >> > On Fri, May 11, 2018 at 6:34 PM, Lucas Stach > >> > e> wrote:
>> >> > > Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King -
>> >> > > ARM Linux:
>> >> > > > On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
>> >> > > > > Hi,
>> >> > > > >
>> >> > > > > I need one help.
>> >> > > > > I am using i.MX7 Sabre board with kernel version 4.1.15
>> >> > > > >
>> >> > > > > Let's say I am interested in GPIO number: 21
>> >> > > > > I wanted to set CPU affinity for particular GPIO->IRQ number,
>> >> > > > > so I
>> >> > > > > tried the below steps:
>> >> > > > > root@10:~# echo 21 > /sys/class/gpio/export
>> >> > > > > root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
>> >> > > > > root@10:~# cat /proc/interrupts | grep 21
>> >> > > > >   47: 0 0 gpio-mxc 21 Edge gpiolib
>> >> > > > > root@10:~# cat /sys/class/gpio/gpio21/direction
>> >> > > > > in
>> >> > > > > root@10:~# cat /proc/irq/47/smp_affinity
>> >> > > > > 3
>> >> > > > > root@10:~# echo 2 > /proc/irq/47/smp_affinity
>> >> > > > > -bash: echo: write error: Input/output error
>> >> > > > >
>> >> > > > > But I get input/output error.
>> >> > > > > When I debug further, found that irq_can_set_affinity is
>> >> > > &

Re: Delivery Status Notification (Failure)

[Pintu Kumar]

On Mon, May 14, 2018 at 7:58 PM, Pintu Kumar <pintu.p...@gmail.com> wrote:
>
> On Mon, May 14, 2018 at 6:41 PM, Lucas Stach <l.st...@pengutronix.de> wrote:
> > Am Montag, den 14.05.2018, 17:42 +0530 schrieb Pintu Kumar:
> >> Hi,
> >>
> >> Is there any work around possible to set IRQ affinity for some GPIO
> >> interrupt ?
> >> How to avoid CPU0 to receive the current GPIO interrupt ?
> >> How do we assign GPIO interrupts to any CPU other than CPU0 ?
> >> Is it possible to isolate CPU0 for a sometime, from my GPIO driver so
> >> that GPIO interrupt can be served by another CPU ?
> >>
> >> Need your inputs to decide whether it is still possible to set
> >> affinity for GPIO interrupt, or its impossible ?
> >
> > This is not possible. The GPIO IRQs are aggregated into one GPC/GIC IRQ
> > line per GPIO bank, so it is not possible to change affinity of a
> > single GPIO interrupt to another CPU.
>
> OK. Thanks for your confirmation.
>
> > Best we could do is change the
> > affinity of the whole bank,
>

Hi,

I found that the driver is responsible for setting GPIO bank in i.MX7:
https://elixir.bootlin.com/linux/v4.2/source/drivers/gpio/gpio-mxc.c

However I still dont know how to set the cpumask for one of the GPIO Bank.

>From this link, it seems it is possible to set affinity for a GPIO IRQ.
https://community.nxp.com/thread/303144

But when I try it form my GPIO138 (GPIO5_IO10) it did not help.

So, as you said, I wanted to change affinity for the whole GPIO bank and try it.
Please give me some pointers.

Thanks


> OK. How can we do this on the fly from my driver code.
> If you have any reference please let me know.
> This is required only for experimental purpose to prove the point to be mgmt.
> My idea is, from the driver, change the affinity of the whole bank.
> So, the GPIO interrupt can be delivered on to this specific CPU bank.
> Once I am done, I will revert back to the old bank.
> Please give me some hint on how to do this from my kernel module....
>
>
> > but given the limited usefulness of
> > something like that, nobody bothered to implement such a thing.
> >
> > Regards,
> > Lucas
> >
> >>
> >>
> >> On Fri, May 11, 2018 at 8:07 PM, Pintu Kumar <pintu.p...@gmail.com>
> >> wrote:
> >> > On Fri, May 11, 2018 at 6:34 PM, Lucas Stach <l.stach@pengutronix.d
> >> > e> wrote:
> >> > > Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King -
> >> > > ARM Linux:
> >> > > > On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
> >> > > > > Hi,
> >> > > > >
> >> > > > > I need one help.
> >> > > > > I am using i.MX7 Sabre board with kernel version 4.1.15
> >> > > > >
> >> > > > > Let's say I am interested in GPIO number: 21
> >> > > > > I wanted to set CPU affinity for particular GPIO->IRQ number,
> >> > > > > so I
> >> > > > > tried the below steps:
> >> > > > > root@10:~# echo 21 > /sys/class/gpio/export
> >> > > > > root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
> >> > > > > root@10:~# cat /proc/interrupts | grep 21
> >> > > > >   47: 0 0 gpio-mxc 21 Edge gpiolib
> >> > > > > root@10:~# cat /sys/class/gpio/gpio21/direction
> >> > > > > in
> >> > > > > root@10:~# cat /proc/irq/47/smp_affinity
> >> > > > > 3
> >> > > > > root@10:~# echo 2 > /proc/irq/47/smp_affinity
> >> > > > > -bash: echo: write error: Input/output error
> >> > > > >
> >> > > > > But I get input/output error.
> >> > > > > When I debug further, found that irq_can_set_affinity is
> >> > > > > returning 0:
> >> > > > > [0.00] genirq: irq_can_set_affinity (0): balance: 1,
> >> > > > > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
> >> > > > > [0.00] write_irq_affinity: FAIL
> >> > > > >
> >> > > > > I also tried first setting /proc/irq/default_smp_affinity to
> >> > > > > 2 (from 3).
> >> > > > > This change is working, but the smp_affinity setting for the
> >> > > > > new IRQ
> >> > > > > is not working.
> >> > > > >
> >> > > &

Re: Delivery Status Notification (Failure)

[Pintu Kumar]

On Mon, May 14, 2018 at 7:58 PM, Pintu Kumar  wrote:
>
> On Mon, May 14, 2018 at 6:41 PM, Lucas Stach  wrote:
> > Am Montag, den 14.05.2018, 17:42 +0530 schrieb Pintu Kumar:
> >> Hi,
> >>
> >> Is there any work around possible to set IRQ affinity for some GPIO
> >> interrupt ?
> >> How to avoid CPU0 to receive the current GPIO interrupt ?
> >> How do we assign GPIO interrupts to any CPU other than CPU0 ?
> >> Is it possible to isolate CPU0 for a sometime, from my GPIO driver so
> >> that GPIO interrupt can be served by another CPU ?
> >>
> >> Need your inputs to decide whether it is still possible to set
> >> affinity for GPIO interrupt, or its impossible ?
> >
> > This is not possible. The GPIO IRQs are aggregated into one GPC/GIC IRQ
> > line per GPIO bank, so it is not possible to change affinity of a
> > single GPIO interrupt to another CPU.
>
> OK. Thanks for your confirmation.
>
> > Best we could do is change the
> > affinity of the whole bank,
>

Hi,

I found that the driver is responsible for setting GPIO bank in i.MX7:
https://elixir.bootlin.com/linux/v4.2/source/drivers/gpio/gpio-mxc.c

However I still dont know how to set the cpumask for one of the GPIO Bank.

>From this link, it seems it is possible to set affinity for a GPIO IRQ.
https://community.nxp.com/thread/303144

But when I try it form my GPIO138 (GPIO5_IO10) it did not help.

So, as you said, I wanted to change affinity for the whole GPIO bank and try it.
Please give me some pointers.

Thanks


> OK. How can we do this on the fly from my driver code.
> If you have any reference please let me know.
> This is required only for experimental purpose to prove the point to be mgmt.
> My idea is, from the driver, change the affinity of the whole bank.
> So, the GPIO interrupt can be delivered on to this specific CPU bank.
> Once I am done, I will revert back to the old bank.
> Please give me some hint on how to do this from my kernel module
>
>
> > but given the limited usefulness of
> > something like that, nobody bothered to implement such a thing.
> >
> > Regards,
> > Lucas
> >
> >>
> >>
> >> On Fri, May 11, 2018 at 8:07 PM, Pintu Kumar 
> >> wrote:
> >> > On Fri, May 11, 2018 at 6:34 PM, Lucas Stach  >> > e> wrote:
> >> > > Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King -
> >> > > ARM Linux:
> >> > > > On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
> >> > > > > Hi,
> >> > > > >
> >> > > > > I need one help.
> >> > > > > I am using i.MX7 Sabre board with kernel version 4.1.15
> >> > > > >
> >> > > > > Let's say I am interested in GPIO number: 21
> >> > > > > I wanted to set CPU affinity for particular GPIO->IRQ number,
> >> > > > > so I
> >> > > > > tried the below steps:
> >> > > > > root@10:~# echo 21 > /sys/class/gpio/export
> >> > > > > root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
> >> > > > > root@10:~# cat /proc/interrupts | grep 21
> >> > > > >   47: 0 0 gpio-mxc 21 Edge gpiolib
> >> > > > > root@10:~# cat /sys/class/gpio/gpio21/direction
> >> > > > > in
> >> > > > > root@10:~# cat /proc/irq/47/smp_affinity
> >> > > > > 3
> >> > > > > root@10:~# echo 2 > /proc/irq/47/smp_affinity
> >> > > > > -bash: echo: write error: Input/output error
> >> > > > >
> >> > > > > But I get input/output error.
> >> > > > > When I debug further, found that irq_can_set_affinity is
> >> > > > > returning 0:
> >> > > > > [0.00] genirq: irq_can_set_affinity (0): balance: 1,
> >> > > > > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
> >> > > > > [0.00] write_irq_affinity: FAIL
> >> > > > >
> >> > > > > I also tried first setting /proc/irq/default_smp_affinity to
> >> > > > > 2 (from 3).
> >> > > > > This change is working, but the smp_affinity setting for the
> >> > > > > new IRQ
> >> > > > > is not working.
> >> > > > >
> >> > > > > When I try to set smp_affinity for mmc0, then it works.
> >> > > > > # cat /proc/in

Re: Delivery Status Notification (Failure)

[Pintu Kumar]

On Mon, May 14, 2018 at 6:41 PM, Lucas Stach <l.st...@pengutronix.de> wrote:
> Am Montag, den 14.05.2018, 17:42 +0530 schrieb Pintu Kumar:
>> Hi,
>>
>> Is there any work around possible to set IRQ affinity for some GPIO
>> interrupt ?
>> How to avoid CPU0 to receive the current GPIO interrupt ?
>> How do we assign GPIO interrupts to any CPU other than CPU0 ?
>> Is it possible to isolate CPU0 for a sometime, from my GPIO driver so
>> that GPIO interrupt can be served by another CPU ?
>>
>> Need your inputs to decide whether it is still possible to set
>> affinity for GPIO interrupt, or its impossible ?
>
> This is not possible. The GPIO IRQs are aggregated into one GPC/GIC IRQ
> line per GPIO bank, so it is not possible to change affinity of a
> single GPIO interrupt to another CPU.

OK. Thanks for your confirmation.

> Best we could do is change the
> affinity of the whole bank,

OK. How can we do this on the fly from my driver code.
If you have any reference please let me know.
This is required only for experimental purpose to prove the point to be mgmt.
My idea is, from the driver, change the affinity of the whole bank.
So, the GPIO interrupt can be delivered on to this specific CPU bank.
Once I am done, I will revert back to the old bank.
Please give me some hint on how to do this from my kernel module


> but given the limited usefulness of
> something like that, nobody bothered to implement such a thing.
>
> Regards,
> Lucas
>
>>
>>
>> On Fri, May 11, 2018 at 8:07 PM, Pintu Kumar <pintu.p...@gmail.com>
>> wrote:
>> > On Fri, May 11, 2018 at 6:34 PM, Lucas Stach <l.stach@pengutronix.d
>> > e> wrote:
>> > > Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King -
>> > > ARM Linux:
>> > > > On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
>> > > > > Hi,
>> > > > >
>> > > > > I need one help.
>> > > > > I am using i.MX7 Sabre board with kernel version 4.1.15
>> > > > >
>> > > > > Let's say I am interested in GPIO number: 21
>> > > > > I wanted to set CPU affinity for particular GPIO->IRQ number,
>> > > > > so I
>> > > > > tried the below steps:
>> > > > > root@10:~# echo 21 > /sys/class/gpio/export
>> > > > > root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
>> > > > > root@10:~# cat /proc/interrupts | grep 21
>> > > > >   47: 0 0 gpio-mxc 21 Edge gpiolib
>> > > > > root@10:~# cat /sys/class/gpio/gpio21/direction
>> > > > > in
>> > > > > root@10:~# cat /proc/irq/47/smp_affinity
>> > > > > 3
>> > > > > root@10:~# echo 2 > /proc/irq/47/smp_affinity
>> > > > > -bash: echo: write error: Input/output error
>> > > > >
>> > > > > But I get input/output error.
>> > > > > When I debug further, found that irq_can_set_affinity is
>> > > > > returning 0:
>> > > > > [0.00] genirq: irq_can_set_affinity (0): balance: 1,
>> > > > > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
>> > > > > [0.00] write_irq_affinity: FAIL
>> > > > >
>> > > > > I also tried first setting /proc/irq/default_smp_affinity to
>> > > > > 2 (from 3).
>> > > > > This change is working, but the smp_affinity setting for the
>> > > > > new IRQ
>> > > > > is not working.
>> > > > >
>> > > > > When I try to set smp_affinity for mmc0, then it works.
>> > > > > # cat /proc/interrupts | grep mmc
>> > > > > 295: 55  0 GPCV2  22 Edge  mmc0
>> > > > > 296:  0  0 GPCV2  23 Edge  mmc1
>> > > > > 297: 52  0 GPCV2  24 Edge  mmc2
>> > > > >
>> > > > > root@10:~# echo 2 > /proc/irq/295/smp_affinity
>> > > > > root@10:~#
>> > > > >
>> > > > >
>> > > > > So, I wanted to know what are the conditions for which
>> > > > > setting
>> > > > > smp_affinity for an IRQ will work ?
>> > > > >
>> > > > > Is there any way by which I can set CPU affinity to a GPIO ->
>> > > > > IRQ ?
>> > > > > Whether, irq_set_affinity_hint() will work in this

Re: Delivery Status Notification (Failure)

[Pintu Kumar]

On Mon, May 14, 2018 at 6:41 PM, Lucas Stach  wrote:
> Am Montag, den 14.05.2018, 17:42 +0530 schrieb Pintu Kumar:
>> Hi,
>>
>> Is there any work around possible to set IRQ affinity for some GPIO
>> interrupt ?
>> How to avoid CPU0 to receive the current GPIO interrupt ?
>> How do we assign GPIO interrupts to any CPU other than CPU0 ?
>> Is it possible to isolate CPU0 for a sometime, from my GPIO driver so
>> that GPIO interrupt can be served by another CPU ?
>>
>> Need your inputs to decide whether it is still possible to set
>> affinity for GPIO interrupt, or its impossible ?
>
> This is not possible. The GPIO IRQs are aggregated into one GPC/GIC IRQ
> line per GPIO bank, so it is not possible to change affinity of a
> single GPIO interrupt to another CPU.

OK. Thanks for your confirmation.

> Best we could do is change the
> affinity of the whole bank,

OK. How can we do this on the fly from my driver code.
If you have any reference please let me know.
This is required only for experimental purpose to prove the point to be mgmt.
My idea is, from the driver, change the affinity of the whole bank.
So, the GPIO interrupt can be delivered on to this specific CPU bank.
Once I am done, I will revert back to the old bank.
Please give me some hint on how to do this from my kernel module


> but given the limited usefulness of
> something like that, nobody bothered to implement such a thing.
>
> Regards,
> Lucas
>
>>
>>
>> On Fri, May 11, 2018 at 8:07 PM, Pintu Kumar 
>> wrote:
>> > On Fri, May 11, 2018 at 6:34 PM, Lucas Stach > > e> wrote:
>> > > Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King -
>> > > ARM Linux:
>> > > > On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
>> > > > > Hi,
>> > > > >
>> > > > > I need one help.
>> > > > > I am using i.MX7 Sabre board with kernel version 4.1.15
>> > > > >
>> > > > > Let's say I am interested in GPIO number: 21
>> > > > > I wanted to set CPU affinity for particular GPIO->IRQ number,
>> > > > > so I
>> > > > > tried the below steps:
>> > > > > root@10:~# echo 21 > /sys/class/gpio/export
>> > > > > root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
>> > > > > root@10:~# cat /proc/interrupts | grep 21
>> > > > >   47: 0 0 gpio-mxc 21 Edge gpiolib
>> > > > > root@10:~# cat /sys/class/gpio/gpio21/direction
>> > > > > in
>> > > > > root@10:~# cat /proc/irq/47/smp_affinity
>> > > > > 3
>> > > > > root@10:~# echo 2 > /proc/irq/47/smp_affinity
>> > > > > -bash: echo: write error: Input/output error
>> > > > >
>> > > > > But I get input/output error.
>> > > > > When I debug further, found that irq_can_set_affinity is
>> > > > > returning 0:
>> > > > > [0.00] genirq: irq_can_set_affinity (0): balance: 1,
>> > > > > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
>> > > > > [0.00] write_irq_affinity: FAIL
>> > > > >
>> > > > > I also tried first setting /proc/irq/default_smp_affinity to
>> > > > > 2 (from 3).
>> > > > > This change is working, but the smp_affinity setting for the
>> > > > > new IRQ
>> > > > > is not working.
>> > > > >
>> > > > > When I try to set smp_affinity for mmc0, then it works.
>> > > > > # cat /proc/interrupts | grep mmc
>> > > > > 295: 55  0 GPCV2  22 Edge  mmc0
>> > > > > 296:  0  0 GPCV2  23 Edge  mmc1
>> > > > > 297: 52  0 GPCV2  24 Edge  mmc2
>> > > > >
>> > > > > root@10:~# echo 2 > /proc/irq/295/smp_affinity
>> > > > > root@10:~#
>> > > > >
>> > > > >
>> > > > > So, I wanted to know what are the conditions for which
>> > > > > setting
>> > > > > smp_affinity for an IRQ will work ?
>> > > > >
>> > > > > Is there any way by which I can set CPU affinity to a GPIO ->
>> > > > > IRQ ?
>> > > > > Whether, irq_set_affinity_hint() will work in this case ?
>> > > >
>> > > > IRQ affinity is only supported 

Re: Delivery Status Notification (Failure)

[Pintu Kumar]

Hi,

Is there any work around possible to set IRQ affinity for some GPIO interrupt ?
How to avoid CPU0 to receive the current GPIO interrupt ?
How do we assign GPIO interrupts to any CPU other than CPU0 ?
Is it possible to isolate CPU0 for a sometime, from my GPIO driver so
that GPIO interrupt can be served by another CPU ?

Need your inputs to decide whether it is still possible to set
affinity for GPIO interrupt, or its impossible ?


Thanks,
Pintu



On Fri, May 11, 2018 at 8:07 PM, Pintu Kumar <pintu.p...@gmail.com> wrote:
> On Fri, May 11, 2018 at 6:34 PM, Lucas Stach <l.st...@pengutronix.de> wrote:
>> Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King - ARM Linux:
>>> On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
>>> > Hi,
>>> >
>>> > I need one help.
>>> > I am using i.MX7 Sabre board with kernel version 4.1.15
>>> >
>>> > Let's say I am interested in GPIO number: 21
>>> > I wanted to set CPU affinity for particular GPIO->IRQ number, so I
>>> > tried the below steps:
>>> > root@10:~# echo 21 > /sys/class/gpio/export
>>> > root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
>>> > root@10:~# cat /proc/interrupts | grep 21
>>> >   47: 0 0 gpio-mxc 21 Edge gpiolib
>>> > root@10:~# cat /sys/class/gpio/gpio21/direction
>>> > in
>>> > root@10:~# cat /proc/irq/47/smp_affinity
>>> > 3
>>> > root@10:~# echo 2 > /proc/irq/47/smp_affinity
>>> > -bash: echo: write error: Input/output error
>>> >
>>> > But I get input/output error.
>>> > When I debug further, found that irq_can_set_affinity is returning 0:
>>> > [0.00] genirq: irq_can_set_affinity (0): balance: 1,
>>> > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
>>> > [0.00] write_irq_affinity: FAIL
>>> >
>>> > I also tried first setting /proc/irq/default_smp_affinity to 2 (from 3).
>>> > This change is working, but the smp_affinity setting for the new IRQ
>>> > is not working.
>>> >
>>> > When I try to set smp_affinity for mmc0, then it works.
>>> > # cat /proc/interrupts | grep mmc
>>> > 295: 55  0 GPCV2  22 Edge  mmc0
>>> > 296:  0  0 GPCV2  23 Edge  mmc1
>>> > 297: 52  0 GPCV2  24 Edge  mmc2
>>> >
>>> > root@10:~# echo 2 > /proc/irq/295/smp_affinity
>>> > root@10:~#
>>> >
>>> >
>>> > So, I wanted to know what are the conditions for which setting
>>> > smp_affinity for an IRQ will work ?
>>> >
>>> > Is there any way by which I can set CPU affinity to a GPIO -> IRQ ?
>>> > Whether, irq_set_affinity_hint() will work in this case ?
>>>
>>> IRQ affinity is only supported where interrupts are _directly_ wired to
>>> the GIC.  It's the GIC which does the interrupt steering to the CPU
>>> cores.
>>>
>>> Interrupts on downstream interrupt controllers (such as GPCV2) have no
>>> ability to be directed independently to other CPUs - the only possible
>>> way to change the mapping is to move _all_ interrupts on that controller,
>>> and any downstream chained interrupts at GIC level.
>>>
>>> Hence why Interrupt 295 has no irq_set_affinity function: there is no way
>>> for the interrupt controller itself to change the affinity of the input
>>> interrupt.
>>
>> The GPCv2 though is a secondary IRQ controller which has a 1:1 mapping
>> of its input IRQs to the upstream GIC IRQ lines. Affinity can thus be
>> handled by forwarding the request to the GIC by
>> irq_chip_set_affinity_parent().
>>
>> As this is handled correctly in the upstream kernel since the first
>> commit introducing support for the GPCv2, it seems the issue is only
>> present in some downstream kernel.
>>
>
> OK. Thanks so much for your reply.
>
> I saw some of the drivers using irq_set_affinity_hint() to force the
> IRQ affinity to a particular CPU.
> This is the sample:
> {
> cpumask_clear(mask);
> cpumask_set_cpu(cpu, mask);
> irq_set_affinity_hint(irq, mask);
> }
>
> Whether this logic will work for a particular GPIO pin ?
>
>
>> Regards,
>> Lucas

Re: Delivery Status Notification (Failure)

[Pintu Kumar]

Hi,

Is there any work around possible to set IRQ affinity for some GPIO interrupt ?
How to avoid CPU0 to receive the current GPIO interrupt ?
How do we assign GPIO interrupts to any CPU other than CPU0 ?
Is it possible to isolate CPU0 for a sometime, from my GPIO driver so
that GPIO interrupt can be served by another CPU ?

Need your inputs to decide whether it is still possible to set
affinity for GPIO interrupt, or its impossible ?


Thanks,
Pintu



On Fri, May 11, 2018 at 8:07 PM, Pintu Kumar  wrote:
> On Fri, May 11, 2018 at 6:34 PM, Lucas Stach  wrote:
>> Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King - ARM Linux:
>>> On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
>>> > Hi,
>>> >
>>> > I need one help.
>>> > I am using i.MX7 Sabre board with kernel version 4.1.15
>>> >
>>> > Let's say I am interested in GPIO number: 21
>>> > I wanted to set CPU affinity for particular GPIO->IRQ number, so I
>>> > tried the below steps:
>>> > root@10:~# echo 21 > /sys/class/gpio/export
>>> > root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
>>> > root@10:~# cat /proc/interrupts | grep 21
>>> >   47: 0 0 gpio-mxc 21 Edge gpiolib
>>> > root@10:~# cat /sys/class/gpio/gpio21/direction
>>> > in
>>> > root@10:~# cat /proc/irq/47/smp_affinity
>>> > 3
>>> > root@10:~# echo 2 > /proc/irq/47/smp_affinity
>>> > -bash: echo: write error: Input/output error
>>> >
>>> > But I get input/output error.
>>> > When I debug further, found that irq_can_set_affinity is returning 0:
>>> > [0.00] genirq: irq_can_set_affinity (0): balance: 1,
>>> > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
>>> > [0.00] write_irq_affinity: FAIL
>>> >
>>> > I also tried first setting /proc/irq/default_smp_affinity to 2 (from 3).
>>> > This change is working, but the smp_affinity setting for the new IRQ
>>> > is not working.
>>> >
>>> > When I try to set smp_affinity for mmc0, then it works.
>>> > # cat /proc/interrupts | grep mmc
>>> > 295: 55  0 GPCV2  22 Edge  mmc0
>>> > 296:  0  0 GPCV2  23 Edge  mmc1
>>> > 297: 52  0 GPCV2  24 Edge  mmc2
>>> >
>>> > root@10:~# echo 2 > /proc/irq/295/smp_affinity
>>> > root@10:~#
>>> >
>>> >
>>> > So, I wanted to know what are the conditions for which setting
>>> > smp_affinity for an IRQ will work ?
>>> >
>>> > Is there any way by which I can set CPU affinity to a GPIO -> IRQ ?
>>> > Whether, irq_set_affinity_hint() will work in this case ?
>>>
>>> IRQ affinity is only supported where interrupts are _directly_ wired to
>>> the GIC.  It's the GIC which does the interrupt steering to the CPU
>>> cores.
>>>
>>> Interrupts on downstream interrupt controllers (such as GPCV2) have no
>>> ability to be directed independently to other CPUs - the only possible
>>> way to change the mapping is to move _all_ interrupts on that controller,
>>> and any downstream chained interrupts at GIC level.
>>>
>>> Hence why Interrupt 295 has no irq_set_affinity function: there is no way
>>> for the interrupt controller itself to change the affinity of the input
>>> interrupt.
>>
>> The GPCv2 though is a secondary IRQ controller which has a 1:1 mapping
>> of its input IRQs to the upstream GIC IRQ lines. Affinity can thus be
>> handled by forwarding the request to the GIC by
>> irq_chip_set_affinity_parent().
>>
>> As this is handled correctly in the upstream kernel since the first
>> commit introducing support for the GPCv2, it seems the issue is only
>> present in some downstream kernel.
>>
>
> OK. Thanks so much for your reply.
>
> I saw some of the drivers using irq_set_affinity_hint() to force the
> IRQ affinity to a particular CPU.
> This is the sample:
> {
> cpumask_clear(mask);
> cpumask_set_cpu(cpu, mask);
> irq_set_affinity_hint(irq, mask);
> }
>
> Whether this logic will work for a particular GPIO pin ?
>
>
>> Regards,
>> Lucas

Re: [PATCH] selftests: android: delete RUN_TESTS and EMIT_TESTS overrides

[Pintu Kumar]

On Thu, May 3, 2018 at 2:48 AM, Shuah Khan (Samsung OSG)
<sh...@kernel.org> wrote:
> Delete RUN_TESTS and EMIT_TESTS overrides and use common defines in
> lib.mk. Common defines work just fine and there is no need to define
> custom overrides.
>
> Signed-off-by: Shuah Khan (Samsung OSG) <sh...@kernel.org>
> ---
>  tools/testing/selftests/android/Makefile | 8 
>  1 file changed, 8 deletions(-)
>
> diff --git a/tools/testing/selftests/android/Makefile 
> b/tools/testing/selftests/android/Makefile
> index f6304d2be90c..72c25a3cb658 100644
> --- a/tools/testing/selftests/android/Makefile
> +++ b/tools/testing/selftests/android/Makefile
> @@ -18,10 +18,6 @@ all:
> fi \
> done
>
> -override define RUN_TESTS
> -   @cd $(OUTPUT); ./run.sh
> -endef
> -
>  override define INSTALL_RULE
> mkdir -p $(INSTALL_PATH)
> install -t $(INSTALL_PATH) $(TEST_PROGS) $(TEST_PROGS_EXTENDED) 
> $(TEST_FILES)
> @@ -33,10 +29,6 @@ override define INSTALL_RULE
> done;
>  endef
>
> -override define EMIT_TESTS
> -   echo "./run.sh"
> -endef
> -
>  override define CLEAN
> @for DIR in $(SUBDIRS); do  \
> BUILD_TARGET=$(OUTPUT)/$$DIR;   \
> --
> 2.14.1
>

OK.

Acked-by: Pintu Agarwal <pintu.p...@gmail.com>

---

Note: This mail goes into my spam email box.

Re: [PATCH] selftests: android: delete RUN_TESTS and EMIT_TESTS overrides

[Pintu Kumar]

On Thu, May 3, 2018 at 2:48 AM, Shuah Khan (Samsung OSG)
 wrote:
> Delete RUN_TESTS and EMIT_TESTS overrides and use common defines in
> lib.mk. Common defines work just fine and there is no need to define
> custom overrides.
>
> Signed-off-by: Shuah Khan (Samsung OSG) 
> ---
>  tools/testing/selftests/android/Makefile | 8 
>  1 file changed, 8 deletions(-)
>
> diff --git a/tools/testing/selftests/android/Makefile 
> b/tools/testing/selftests/android/Makefile
> index f6304d2be90c..72c25a3cb658 100644
> --- a/tools/testing/selftests/android/Makefile
> +++ b/tools/testing/selftests/android/Makefile
> @@ -18,10 +18,6 @@ all:
> fi \
> done
>
> -override define RUN_TESTS
> -   @cd $(OUTPUT); ./run.sh
> -endef
> -
>  override define INSTALL_RULE
> mkdir -p $(INSTALL_PATH)
> install -t $(INSTALL_PATH) $(TEST_PROGS) $(TEST_PROGS_EXTENDED) 
> $(TEST_FILES)
> @@ -33,10 +29,6 @@ override define INSTALL_RULE
> done;
>  endef
>
> -override define EMIT_TESTS
> -   echo "./run.sh"
> -endef
> -
>  override define CLEAN
> @for DIR in $(SUBDIRS); do  \
> BUILD_TARGET=$(OUTPUT)/$$DIR;   \
> --
> 2.14.1
>

OK.

Acked-by: Pintu Agarwal 

---

Note: This mail goes into my spam email box.

Re: Delivery Status Notification (Failure)

[Pintu Kumar]

On Fri, May 11, 2018 at 6:34 PM, Lucas Stach <l.st...@pengutronix.de> wrote:
> Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King - ARM Linux:
>> On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
>> > Hi,
>> >
>> > I need one help.
>> > I am using i.MX7 Sabre board with kernel version 4.1.15
>> >
>> > Let's say I am interested in GPIO number: 21
>> > I wanted to set CPU affinity for particular GPIO->IRQ number, so I
>> > tried the below steps:
>> > root@10:~# echo 21 > /sys/class/gpio/export
>> > root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
>> > root@10:~# cat /proc/interrupts | grep 21
>> >   47: 0 0 gpio-mxc 21 Edge gpiolib
>> > root@10:~# cat /sys/class/gpio/gpio21/direction
>> > in
>> > root@10:~# cat /proc/irq/47/smp_affinity
>> > 3
>> > root@10:~# echo 2 > /proc/irq/47/smp_affinity
>> > -bash: echo: write error: Input/output error
>> >
>> > But I get input/output error.
>> > When I debug further, found that irq_can_set_affinity is returning 0:
>> > [0.00] genirq: irq_can_set_affinity (0): balance: 1,
>> > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
>> > [0.00] write_irq_affinity: FAIL
>> >
>> > I also tried first setting /proc/irq/default_smp_affinity to 2 (from 3).
>> > This change is working, but the smp_affinity setting for the new IRQ
>> > is not working.
>> >
>> > When I try to set smp_affinity for mmc0, then it works.
>> > # cat /proc/interrupts | grep mmc
>> > 295: 55  0 GPCV2  22 Edge  mmc0
>> > 296:  0  0 GPCV2  23 Edge  mmc1
>> > 297: 52  0 GPCV2  24 Edge  mmc2
>> >
>> > root@10:~# echo 2 > /proc/irq/295/smp_affinity
>> > root@10:~#
>> >
>> >
>> > So, I wanted to know what are the conditions for which setting
>> > smp_affinity for an IRQ will work ?
>> >
>> > Is there any way by which I can set CPU affinity to a GPIO -> IRQ ?
>> > Whether, irq_set_affinity_hint() will work in this case ?
>>
>> IRQ affinity is only supported where interrupts are _directly_ wired to
>> the GIC.  It's the GIC which does the interrupt steering to the CPU
>> cores.
>>
>> Interrupts on downstream interrupt controllers (such as GPCV2) have no
>> ability to be directed independently to other CPUs - the only possible
>> way to change the mapping is to move _all_ interrupts on that controller,
>> and any downstream chained interrupts at GIC level.
>>
>> Hence why Interrupt 295 has no irq_set_affinity function: there is no way
>> for the interrupt controller itself to change the affinity of the input
>> interrupt.
>
> The GPCv2 though is a secondary IRQ controller which has a 1:1 mapping
> of its input IRQs to the upstream GIC IRQ lines. Affinity can thus be
> handled by forwarding the request to the GIC by
> irq_chip_set_affinity_parent().
>
> As this is handled correctly in the upstream kernel since the first
> commit introducing support for the GPCv2, it seems the issue is only
> present in some downstream kernel.
>

OK. Thanks so much for your reply.

I saw some of the drivers using irq_set_affinity_hint() to force the
IRQ affinity to a particular CPU.
This is the sample:
{
cpumask_clear(mask);
cpumask_set_cpu(cpu, mask);
irq_set_affinity_hint(irq, mask);
}

Whether this logic will work for a particular GPIO pin ?


> Regards,
> Lucas

Re: Delivery Status Notification (Failure)

[Pintu Kumar]

On Fri, May 11, 2018 at 6:34 PM, Lucas Stach  wrote:
> Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King - ARM Linux:
>> On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
>> > Hi,
>> >
>> > I need one help.
>> > I am using i.MX7 Sabre board with kernel version 4.1.15
>> >
>> > Let's say I am interested in GPIO number: 21
>> > I wanted to set CPU affinity for particular GPIO->IRQ number, so I
>> > tried the below steps:
>> > root@10:~# echo 21 > /sys/class/gpio/export
>> > root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
>> > root@10:~# cat /proc/interrupts | grep 21
>> >   47: 0 0 gpio-mxc 21 Edge gpiolib
>> > root@10:~# cat /sys/class/gpio/gpio21/direction
>> > in
>> > root@10:~# cat /proc/irq/47/smp_affinity
>> > 3
>> > root@10:~# echo 2 > /proc/irq/47/smp_affinity
>> > -bash: echo: write error: Input/output error
>> >
>> > But I get input/output error.
>> > When I debug further, found that irq_can_set_affinity is returning 0:
>> > [0.00] genirq: irq_can_set_affinity (0): balance: 1,
>> > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
>> > [0.00] write_irq_affinity: FAIL
>> >
>> > I also tried first setting /proc/irq/default_smp_affinity to 2 (from 3).
>> > This change is working, but the smp_affinity setting for the new IRQ
>> > is not working.
>> >
>> > When I try to set smp_affinity for mmc0, then it works.
>> > # cat /proc/interrupts | grep mmc
>> > 295: 55  0 GPCV2  22 Edge  mmc0
>> > 296:  0  0 GPCV2  23 Edge  mmc1
>> > 297: 52  0 GPCV2  24 Edge  mmc2
>> >
>> > root@10:~# echo 2 > /proc/irq/295/smp_affinity
>> > root@10:~#
>> >
>> >
>> > So, I wanted to know what are the conditions for which setting
>> > smp_affinity for an IRQ will work ?
>> >
>> > Is there any way by which I can set CPU affinity to a GPIO -> IRQ ?
>> > Whether, irq_set_affinity_hint() will work in this case ?
>>
>> IRQ affinity is only supported where interrupts are _directly_ wired to
>> the GIC.  It's the GIC which does the interrupt steering to the CPU
>> cores.
>>
>> Interrupts on downstream interrupt controllers (such as GPCV2) have no
>> ability to be directed independently to other CPUs - the only possible
>> way to change the mapping is to move _all_ interrupts on that controller,
>> and any downstream chained interrupts at GIC level.
>>
>> Hence why Interrupt 295 has no irq_set_affinity function: there is no way
>> for the interrupt controller itself to change the affinity of the input
>> interrupt.
>
> The GPCv2 though is a secondary IRQ controller which has a 1:1 mapping
> of its input IRQs to the upstream GIC IRQ lines. Affinity can thus be
> handled by forwarding the request to the GIC by
> irq_chip_set_affinity_parent().
>
> As this is handled correctly in the upstream kernel since the first
> commit introducing support for the GPCv2, it seems the issue is only
> present in some downstream kernel.
>

OK. Thanks so much for your reply.

I saw some of the drivers using irq_set_affinity_hint() to force the
IRQ affinity to a particular CPU.
This is the sample:
{
cpumask_clear(mask);
cpumask_set_cpu(cpu, mask);
irq_set_affinity_hint(irq, mask);
}

Whether this logic will work for a particular GPIO pin ?


> Regards,
> Lucas

Re: Delivery Status Notification (Failure)

[Pintu Kumar]

Hi,

I need one help.
I am using i.MX7 Sabre board with kernel version 4.1.15

Let's say I am interested in GPIO number: 21
I wanted to set CPU affinity for particular GPIO->IRQ number, so I
tried the below steps:
root@10:~# echo 21 > /sys/class/gpio/export
root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
root@10:~# cat /proc/interrupts | grep 21
  47: 0 0 gpio-mxc 21 Edge gpiolib
root@10:~# cat /sys/class/gpio/gpio21/direction
in
root@10:~# cat /proc/irq/47/smp_affinity
3
root@10:~# echo 2 > /proc/irq/47/smp_affinity
-bash: echo: write error: Input/output error

But I get input/output error.
When I debug further, found that irq_can_set_affinity is returning 0:
[0.00] genirq: irq_can_set_affinity (0): balance: 1,
irq_data.chip: a81b7e48, irq_set_affinity:   (null)
[0.00] write_irq_affinity: FAIL

I also tried first setting /proc/irq/default_smp_affinity to 2 (from 3).
This change is working, but the smp_affinity setting for the new IRQ
is not working.

When I try to set smp_affinity for mmc0, then it works.
# cat /proc/interrupts | grep mmc
295: 55  0 GPCV2  22 Edge  mmc0
296:  0  0 GPCV2  23 Edge  mmc1
297: 52  0 GPCV2  24 Edge  mmc2

root@10:~# echo 2 > /proc/irq/295/smp_affinity
root@10:~#


So, I wanted to know what are the conditions for which setting
smp_affinity for an IRQ will work ?

Is there any way by which I can set CPU affinity to a GPIO -> IRQ ?
Whether, irq_set_affinity_hint() will work in this case ?


Thanks,
Pintu

Re: Delivery Status Notification (Failure)

[Pintu Kumar]

Hi,

I need one help.
I am using i.MX7 Sabre board with kernel version 4.1.15

Let's say I am interested in GPIO number: 21
I wanted to set CPU affinity for particular GPIO->IRQ number, so I
tried the below steps:
root@10:~# echo 21 > /sys/class/gpio/export
root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
root@10:~# cat /proc/interrupts | grep 21
  47: 0 0 gpio-mxc 21 Edge gpiolib
root@10:~# cat /sys/class/gpio/gpio21/direction
in
root@10:~# cat /proc/irq/47/smp_affinity
3
root@10:~# echo 2 > /proc/irq/47/smp_affinity
-bash: echo: write error: Input/output error

But I get input/output error.
When I debug further, found that irq_can_set_affinity is returning 0:
[0.00] genirq: irq_can_set_affinity (0): balance: 1,
irq_data.chip: a81b7e48, irq_set_affinity:   (null)
[0.00] write_irq_affinity: FAIL

I also tried first setting /proc/irq/default_smp_affinity to 2 (from 3).
This change is working, but the smp_affinity setting for the new IRQ
is not working.

When I try to set smp_affinity for mmc0, then it works.
# cat /proc/interrupts | grep mmc
295: 55  0 GPCV2  22 Edge  mmc0
296:  0  0 GPCV2  23 Edge  mmc1
297: 52  0 GPCV2  24 Edge  mmc2

root@10:~# echo 2 > /proc/irq/295/smp_affinity
root@10:~#


So, I wanted to know what are the conditions for which setting
smp_affinity for an IRQ will work ?

Is there any way by which I can set CPU affinity to a GPIO -> IRQ ?
Whether, irq_set_affinity_hint() will work in this case ?


Thanks,
Pintu

Re: [PATCH 01/24] selftests: android: ion: return Kselftest Skip code for skipped tests

[Pintu Kumar]

On Sat, May 5, 2018 at 6:43 AM, Shuah Khan (Samsung OSG)
<sh...@kernel.org> wrote:
> When ion test is skipped because of unmet dependencies and/or unsupported
> configuration, it returns 0 which is treated as a pass by the Kselftest
> framework. This leads to false positive result even when the test could
> not be run.
>
> Change it to return kselftest skip code when a test gets skipped to
> clearly report that the test could not be run.
>
> Kselftest framework SKIP code is 4 and the framework prints appropriate
> messages to indicate that the test is skipped.
>
> Signed-off-by: Shuah Khan (Samsung OSG) <sh...@kernel.org>
> ---
>  tools/testing/selftests/android/ion/ion_test.sh | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/tools/testing/selftests/android/ion/ion_test.sh 
> b/tools/testing/selftests/android/ion/ion_test.sh
> index a1aff506f5e6..69e676cfc94e 100755
> --- a/tools/testing/selftests/android/ion/ion_test.sh
> +++ b/tools/testing/selftests/android/ion/ion_test.sh
> @@ -4,6 +4,9 @@ heapsize=4096
>  TCID="ion_test.sh"
>  errcode=0
>
> +# Kselftest framework requirement - SKIP code is 4.
> +ksft_skip=4
> +
>  run_test()
>  {
> heaptype=$1
> @@ -25,7 +28,7 @@ check_root()
> uid=$(id -u)
> if [ $uid -ne 0 ]; then
> echo $TCID: must be run as root >&2
> -   exit 0
> +   exit $ksft_skip
> fi
>  }
>
> @@ -35,7 +38,7 @@ check_device()
> if [ ! -e $DEVICE ]; then
> echo $TCID: No $DEVICE device found >&2
>     echo $TCID: May be CONFIG_ION is not set >&2
> -   exit 0
> +   exit $ksft_skip
> fi
>  }
>

Ok changes looks good to me.

Acked-by: Pintu Agarwal <pintu.p...@gmail.com>


> --
> 2.14.1
>

Re: [PATCH 01/24] selftests: android: ion: return Kselftest Skip code for skipped tests

[Pintu Kumar]

On Sat, May 5, 2018 at 6:43 AM, Shuah Khan (Samsung OSG)
 wrote:
> When ion test is skipped because of unmet dependencies and/or unsupported
> configuration, it returns 0 which is treated as a pass by the Kselftest
> framework. This leads to false positive result even when the test could
> not be run.
>
> Change it to return kselftest skip code when a test gets skipped to
> clearly report that the test could not be run.
>
> Kselftest framework SKIP code is 4 and the framework prints appropriate
> messages to indicate that the test is skipped.
>
> Signed-off-by: Shuah Khan (Samsung OSG) 
> ---
>  tools/testing/selftests/android/ion/ion_test.sh | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/tools/testing/selftests/android/ion/ion_test.sh 
> b/tools/testing/selftests/android/ion/ion_test.sh
> index a1aff506f5e6..69e676cfc94e 100755
> --- a/tools/testing/selftests/android/ion/ion_test.sh
> +++ b/tools/testing/selftests/android/ion/ion_test.sh
> @@ -4,6 +4,9 @@ heapsize=4096
>  TCID="ion_test.sh"
>  errcode=0
>
> +# Kselftest framework requirement - SKIP code is 4.
> +ksft_skip=4
> +
>  run_test()
>  {
> heaptype=$1
> @@ -25,7 +28,7 @@ check_root()
> uid=$(id -u)
> if [ $uid -ne 0 ]; then
> echo $TCID: must be run as root >&2
> -   exit 0
> +   exit $ksft_skip
> fi
>  }
>
> @@ -35,7 +38,7 @@ check_device()
> if [ ! -e $DEVICE ]; then
> echo $TCID: No $DEVICE device found >&2
> echo $TCID: May be CONFIG_ION is not set >&2
> -   exit 0
> +   exit $ksft_skip
> fi
>  }
>

Ok changes looks good to me.

Acked-by: Pintu Agarwal 


> --
> 2.14.1
>

Re: [HELP] CPU Hard LOCKUP during boot up with HPET clock source

[Pintu Kumar]

Hi,

As a simple query,
Is there a way to skip current available clock source (hpet) and allow
to pick the next one ?
I guess this will solve our purpose.


Thanks,
Pintu


On Fri, Apr 6, 2018 at 8:37 PM, Pintu Kumar <pintu.p...@gmail.com> wrote:
> Hi,
>
> First the few details:
> Kernel: 4.9.20
> Machine: x86_64 (AMD)
> Model: Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz
> Cores: 8
> Available clock source:
> # cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> tsc hpet acpi_pm
>
> Problem:
> [   28.027409] NMI watchdog: Watchdog detected hard LOCKUP on cpu
> 1dModules linked in:c
> [   28.136317] RIP: 0010:[] c []
> read_hpet+0xb3/0x120
> [...]
>
> --
> This lockup happens during boot when the cpu is stuck for about ~28 seconds.
> This is because of our internal code changes.
> During our init function we are running some calibrate loops
> 10,000,000 (10MHz) times twice.
> The LOCKUP is coming because of this loop.
>
> But, we observed that the main issue is the clock source that is
> available at that time.
> At the time this loop is executed, the available clock source is HPET (not 
> TSC).
> With HPET the loop runs slower. It takes almost 28 seconds to complete
> with HPET clock source. Hence the boot time also increase by 28
> seconds.
> Where as with TSC the loop completes in less than 4 seconds. So, with
> TSC we dont get the LOCKUP.
>
> Thus, the lockup is happening only because the loop executes with HPET
> clock source.
>
> To fix the problem, I tried the following approach:
> 1) Use late_initcall for our driver init to delay the call until TSC
> clock source is ready.
> => With this there is no LOCKUP trace and no impact on boot time.
> This is because the loop executes with TSC.
>
> 2) We have 2 loops. So I split the local_irq_save/restore part for
> each loops separately.
>  => With this also there is no backtrace seen.
>  => But boot time is increased.
>
> 3) I used delayed_workqueue to delay the execution of the loop by 5
> seconds, until TSC is ready.
> => With this there is no back trace and also boot time is normal.
> => But if we disable TSC then we still get the back trace.
>
> 4) Disabled HPET from kernel command line using : hpet=disable
> => This also works as the loop executes with the next available
> clock source: acpi_pm
> => But changing boot args is not recommended in our case.
>
> 5) Disable HPET related configs in kernel
> => CONFIG_HPET=n
> => CONFIG_HPET_TIMER=n
> => This method does not work as we were not able to disable
> HPET_TIMER on x86_64.
>
> 6) Use hpet_disable() from our code.
> => This method also does not work. It actually does not disable
> HPET clock source.
>
>
> -
> Thus we wanted to know your opinion which is the right solution to fix
> this lockup during boot time.
>
> Is there a way to purposefully fallback to next available clock source
> (acpi_pm) instead of hpet, from the source code, before executing our
> loop ?
>
>
> Please let me know if there are alternate options.
>
>
>
> Thanks,
> Pintu

Re: [HELP] CPU Hard LOCKUP during boot up with HPET clock source

[Pintu Kumar]

Hi,

As a simple query,
Is there a way to skip current available clock source (hpet) and allow
to pick the next one ?
I guess this will solve our purpose.


Thanks,
Pintu


On Fri, Apr 6, 2018 at 8:37 PM, Pintu Kumar  wrote:
> Hi,
>
> First the few details:
> Kernel: 4.9.20
> Machine: x86_64 (AMD)
> Model: Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz
> Cores: 8
> Available clock source:
> # cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> tsc hpet acpi_pm
>
> Problem:
> [   28.027409] NMI watchdog: Watchdog detected hard LOCKUP on cpu
> 1dModules linked in:c
> [   28.136317] RIP: 0010:[] c []
> read_hpet+0xb3/0x120
> [...]
>
> --
> This lockup happens during boot when the cpu is stuck for about ~28 seconds.
> This is because of our internal code changes.
> During our init function we are running some calibrate loops
> 10,000,000 (10MHz) times twice.
> The LOCKUP is coming because of this loop.
>
> But, we observed that the main issue is the clock source that is
> available at that time.
> At the time this loop is executed, the available clock source is HPET (not 
> TSC).
> With HPET the loop runs slower. It takes almost 28 seconds to complete
> with HPET clock source. Hence the boot time also increase by 28
> seconds.
> Where as with TSC the loop completes in less than 4 seconds. So, with
> TSC we dont get the LOCKUP.
>
> Thus, the lockup is happening only because the loop executes with HPET
> clock source.
>
> To fix the problem, I tried the following approach:
> 1) Use late_initcall for our driver init to delay the call until TSC
> clock source is ready.
> => With this there is no LOCKUP trace and no impact on boot time.
> This is because the loop executes with TSC.
>
> 2) We have 2 loops. So I split the local_irq_save/restore part for
> each loops separately.
>  => With this also there is no backtrace seen.
>  => But boot time is increased.
>
> 3) I used delayed_workqueue to delay the execution of the loop by 5
> seconds, until TSC is ready.
> => With this there is no back trace and also boot time is normal.
> => But if we disable TSC then we still get the back trace.
>
> 4) Disabled HPET from kernel command line using : hpet=disable
> => This also works as the loop executes with the next available
> clock source: acpi_pm
> => But changing boot args is not recommended in our case.
>
> 5) Disable HPET related configs in kernel
> => CONFIG_HPET=n
> => CONFIG_HPET_TIMER=n
> => This method does not work as we were not able to disable
> HPET_TIMER on x86_64.
>
> 6) Use hpet_disable() from our code.
> => This method also does not work. It actually does not disable
> HPET clock source.
>
>
> -
> Thus we wanted to know your opinion which is the right solution to fix
> this lockup during boot time.
>
> Is there a way to purposefully fallback to next available clock source
> (acpi_pm) instead of hpet, from the source code, before executing our
> loop ?
>
>
> Please let me know if there are alternate options.
>
>
>
> Thanks,
> Pintu

Re: [PATCH v2] selftests/android/ion: fix heap_type may be uninitialized

[Pintu Kumar]

On Thu, Apr 5, 2018 at 1:09 PM, Anders Roxell  wrote:
> gcc warns that 'heap_type' is not initialized if we don't come through
> any of the two 'case' statesments before:
>
> ionapp_export.c:91:2: warning: ‘heap_type’ may be used uninitialized in
> this function [-Wmaybe-uninitialized]
>   printf("heap_type: %ld, heap_size: %ld\n", heap_type, heap_size);
>   ^~~~
>
> In the current code, we initialize the heap_type to -1 before the 'case'
> statements. We also change the print_usage function to state that
> heap_type and heap_size isn't optional, they are mandatory.
>
> Fixes: 47a18c42d992 ("android/ion: userspace test utility for ion buffer 
> sharing")
> Signed-off-by: Anders Roxell 
> ---
>  tools/testing/selftests/android/ion/ionapp_export.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/tools/testing/selftests/android/ion/ionapp_export.c 
> b/tools/testing/selftests/android/ion/ionapp_export.c
> index a944e72621a9..67a0263a7f28 100644
> --- a/tools/testing/selftests/android/ion/ionapp_export.c
> +++ b/tools/testing/selftests/android/ion/ionapp_export.c
> @@ -31,8 +31,10 @@
>
>  void print_usage(int argc, char *argv[])
>  {
> -   printf("Usage: %s [-h ] [-i ] [-s ]\n",
> +   printf("Usage: %s [-h ] -i  -s \n",
> argv[0]);
> +   printf("Supported heap id's 0 or 1\n");
> +   printf("Heap size > 0\n");
>  }
>
>  int main(int argc, char *argv[])
> @@ -40,7 +42,8 @@ int main(int argc, char *argv[])
> int opt, ret, status, heapid;
> int sockfd, client_fd, shared_fd;
> unsigned char *map_buf;
> -   unsigned long map_len, heap_type, heap_size, flags;
> +   unsigned long map_len, heap_size, flags;
> +   long heap_type;
> struct ion_buffer_info info;
> struct socket_info skinfo;
>
> @@ -50,6 +53,7 @@ int main(int argc, char *argv[])
> }
>
> heap_size = 0;
> +   heap_type = -1;
> flags = 0;
>

To make it simple, I would suggest, let the default heap_type be 0.
Actually that was my original intention but I would have missed it
during submission.
In that case nothing below is required to change.

> while ((opt = getopt(argc, argv, "hi:s:")) != -1) {
> @@ -68,7 +72,7 @@ int main(int argc, char *argv[])
> heap_type = ION_HEAP_TYPE_SYSTEM_CONTIG;
> break;
> default:
> -   printf("ERROR: heap type not supported\n");
> +   print_usage(argc, argv);
> exit(1);
> }
> break;
> @@ -82,8 +86,7 @@ int main(int argc, char *argv[])
> }
> }
>
> -   if (heap_size <= 0) {
> -   printf("heap_size cannot be 0\n");
> +   if (heap_size <= 0 || heap_type < 0) {
> print_usage(argc, argv);
> exit(1);
> }
> --
> 2.11.0
>

Re: [PATCH v2] selftests/android/ion: fix heap_type may be uninitialized

[Pintu Kumar]

On Thu, Apr 5, 2018 at 1:09 PM, Anders Roxell  wrote:
> gcc warns that 'heap_type' is not initialized if we don't come through
> any of the two 'case' statesments before:
>
> ionapp_export.c:91:2: warning: ‘heap_type’ may be used uninitialized in
> this function [-Wmaybe-uninitialized]
>   printf("heap_type: %ld, heap_size: %ld\n", heap_type, heap_size);
>   ^~~~
>
> In the current code, we initialize the heap_type to -1 before the 'case'
> statements. We also change the print_usage function to state that
> heap_type and heap_size isn't optional, they are mandatory.
>
> Fixes: 47a18c42d992 ("android/ion: userspace test utility for ion buffer 
> sharing")
> Signed-off-by: Anders Roxell 
> ---
>  tools/testing/selftests/android/ion/ionapp_export.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/tools/testing/selftests/android/ion/ionapp_export.c 
> b/tools/testing/selftests/android/ion/ionapp_export.c
> index a944e72621a9..67a0263a7f28 100644
> --- a/tools/testing/selftests/android/ion/ionapp_export.c
> +++ b/tools/testing/selftests/android/ion/ionapp_export.c
> @@ -31,8 +31,10 @@
>
>  void print_usage(int argc, char *argv[])
>  {
> -   printf("Usage: %s [-h ] [-i ] [-s ]\n",
> +   printf("Usage: %s [-h ] -i  -s \n",
> argv[0]);
> +   printf("Supported heap id's 0 or 1\n");
> +   printf("Heap size > 0\n");
>  }
>
>  int main(int argc, char *argv[])
> @@ -40,7 +42,8 @@ int main(int argc, char *argv[])
> int opt, ret, status, heapid;
> int sockfd, client_fd, shared_fd;
> unsigned char *map_buf;
> -   unsigned long map_len, heap_type, heap_size, flags;
> +   unsigned long map_len, heap_size, flags;
> +   long heap_type;
> struct ion_buffer_info info;
> struct socket_info skinfo;
>
> @@ -50,6 +53,7 @@ int main(int argc, char *argv[])
> }
>
> heap_size = 0;
> +   heap_type = -1;
> flags = 0;
>

To make it simple, I would suggest, let the default heap_type be 0.
Actually that was my original intention but I would have missed it
during submission.
In that case nothing below is required to change.

> while ((opt = getopt(argc, argv, "hi:s:")) != -1) {
> @@ -68,7 +72,7 @@ int main(int argc, char *argv[])
> heap_type = ION_HEAP_TYPE_SYSTEM_CONTIG;
> break;
> default:
> -   printf("ERROR: heap type not supported\n");
> +   print_usage(argc, argv);
> exit(1);
> }
> break;
> @@ -82,8 +86,7 @@ int main(int argc, char *argv[])
> }
> }
>
> -   if (heap_size <= 0) {
> -   printf("heap_size cannot be 0\n");
> +   if (heap_size <= 0 || heap_type < 0) {
> print_usage(argc, argv);
> exit(1);
> }
> --
> 2.11.0
>

[HELP] CPU Hard LOCKUP during boot up with HPET clock source

[Pintu Kumar]

Hi,

First the few details:
Kernel: 4.9.20
Machine: x86_64 (AMD)
Model: Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz
Cores: 8
Available clock source:
# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm

Problem:
[   28.027409] NMI watchdog: Watchdog detected hard LOCKUP on cpu
1dModules linked in:c
[   28.136317] RIP: 0010:[] c []
read_hpet+0xb3/0x120
[...]

--
This lockup happens during boot when the cpu is stuck for about ~28 seconds.
This is because of our internal code changes.
During our init function we are running some calibrate loops
10,000,000 (10MHz) times twice.
The LOCKUP is coming because of this loop.

But, we observed that the main issue is the clock source that is
available at that time.
At the time this loop is executed, the available clock source is HPET (not TSC).
With HPET the loop runs slower. It takes almost 28 seconds to complete
with HPET clock source. Hence the boot time also increase by 28
seconds.
Where as with TSC the loop completes in less than 4 seconds. So, with
TSC we dont get the LOCKUP.

Thus, the lockup is happening only because the loop executes with HPET
clock source.

To fix the problem, I tried the following approach:
1) Use late_initcall for our driver init to delay the call until TSC
clock source is ready.
=> With this there is no LOCKUP trace and no impact on boot time.
This is because the loop executes with TSC.

2) We have 2 loops. So I split the local_irq_save/restore part for
each loops separately.
 => With this also there is no backtrace seen.
 => But boot time is increased.

3) I used delayed_workqueue to delay the execution of the loop by 5
seconds, until TSC is ready.
=> With this there is no back trace and also boot time is normal.
=> But if we disable TSC then we still get the back trace.

4) Disabled HPET from kernel command line using : hpet=disable
=> This also works as the loop executes with the next available
clock source: acpi_pm
=> But changing boot args is not recommended in our case.

5) Disable HPET related configs in kernel
=> CONFIG_HPET=n
=> CONFIG_HPET_TIMER=n
=> This method does not work as we were not able to disable
HPET_TIMER on x86_64.

6) Use hpet_disable() from our code.
=> This method also does not work. It actually does not disable
HPET clock source.


-
Thus we wanted to know your opinion which is the right solution to fix
this lockup during boot time.

Is there a way to purposefully fallback to next available clock source
(acpi_pm) instead of hpet, from the source code, before executing our
loop ?


Please let me know if there are alternate options.



Thanks,
Pintu

[HELP] CPU Hard LOCKUP during boot up with HPET clock source

[Pintu Kumar]

Hi,

First the few details:
Kernel: 4.9.20
Machine: x86_64 (AMD)
Model: Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz
Cores: 8
Available clock source:
# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm

Problem:
[   28.027409] NMI watchdog: Watchdog detected hard LOCKUP on cpu
1dModules linked in:c
[   28.136317] RIP: 0010:[] c []
read_hpet+0xb3/0x120
[...]

--
This lockup happens during boot when the cpu is stuck for about ~28 seconds.
This is because of our internal code changes.
During our init function we are running some calibrate loops
10,000,000 (10MHz) times twice.
The LOCKUP is coming because of this loop.

But, we observed that the main issue is the clock source that is
available at that time.
At the time this loop is executed, the available clock source is HPET (not TSC).
With HPET the loop runs slower. It takes almost 28 seconds to complete
with HPET clock source. Hence the boot time also increase by 28
seconds.
Where as with TSC the loop completes in less than 4 seconds. So, with
TSC we dont get the LOCKUP.

Thus, the lockup is happening only because the loop executes with HPET
clock source.

To fix the problem, I tried the following approach:
1) Use late_initcall for our driver init to delay the call until TSC
clock source is ready.
=> With this there is no LOCKUP trace and no impact on boot time.
This is because the loop executes with TSC.

2) We have 2 loops. So I split the local_irq_save/restore part for
each loops separately.
 => With this also there is no backtrace seen.
 => But boot time is increased.

3) I used delayed_workqueue to delay the execution of the loop by 5
seconds, until TSC is ready.
=> With this there is no back trace and also boot time is normal.
=> But if we disable TSC then we still get the back trace.

4) Disabled HPET from kernel command line using : hpet=disable
=> This also works as the loop executes with the next available
clock source: acpi_pm
=> But changing boot args is not recommended in our case.

5) Disable HPET related configs in kernel
=> CONFIG_HPET=n
=> CONFIG_HPET_TIMER=n
=> This method does not work as we were not able to disable
HPET_TIMER on x86_64.

6) Use hpet_disable() from our code.
=> This method also does not work. It actually does not disable
HPET clock source.


-
Thus we wanted to know your opinion which is the right solution to fix
this lockup during boot time.

Is there a way to purposefully fallback to next available clock source
(acpi_pm) instead of hpet, from the source code, before executing our
loop ?


Please let me know if there are alternate options.



Thanks,
Pintu

Re: [PATCH] selftests/android/ion: fix heap_type may be uninitialized

[Pintu Kumar]

On Thu, Mar 8, 2018 at 7:18 PM, Anders Roxell  wrote:
> gcc warns that 'heap_type' is not initialized if we don't come through
> any of the two 'case' statesments before:
>

OK thanks for your patch.

> ionapp_export.c:91:2: warning: ‘heap_type’ may be used uninitialized in
> this function [-Wmaybe-uninitialized]
>   printf("heap_type: %ld, heap_size: %ld\n", heap_type, heap_size);
>   ^~~~
>
> In the current code, we initialize the heap_type to -1 before the 'case'
> statements. We also change the print_usage function to state that
> heap_type and heap_size isn't optional, they are mandatory.
>

OK

> Fixes: 47a18c42d992 ("android/ion: userspace test utility for ion buffer 
> sharing")
> Signed-off-by: Anders Roxell 
> ---
>  .../testing/selftests/android/ion/ionapp_export.c  | 23 
> +++---
>  1 file changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/tools/testing/selftests/android/ion/ionapp_export.c 
> b/tools/testing/selftests/android/ion/ionapp_export.c
> index a944e72621a9..b42f803e9d2a 100644
> --- a/tools/testing/selftests/android/ion/ionapp_export.c
> +++ b/tools/testing/selftests/android/ion/ionapp_export.c
> @@ -31,16 +31,24 @@
>
>  void print_usage(int argc, char *argv[])
>  {
> -   printf("Usage: %s [-h ] [-i ] [-s ]\n",
> +   printf("Usage: %s [-h ] -i  -s \n",
> argv[0]);
>  }
>
> +void heap_type_error_text(void)
> +{
> +   printf("heap_type must be specified\n");
> +   printf("  need to specify -i \n");
> +   printf("  supported heap types 0 or 1\n");
> +}
> +

I think this error function needs to be generic.
See explanation below.


>  int main(int argc, char *argv[])
>  {
> int opt, ret, status, heapid;
> int sockfd, client_fd, shared_fd;
> unsigned char *map_buf;
> -   unsigned long map_len, heap_type, heap_size, flags;
> +   unsigned long map_len, heap_size, flags;
> +   long heap_type;
> struct ion_buffer_info info;
> struct socket_info skinfo;
>
> @@ -50,6 +58,7 @@ int main(int argc, char *argv[])
> }
>
> heap_size = 0;
> +   heap_type = -1;
> flags = 0;
>
> while ((opt = getopt(argc, argv, "hi:s:")) != -1) {
> @@ -68,7 +77,8 @@ int main(int argc, char *argv[])
> heap_type = ION_HEAP_TYPE_SYSTEM_CONTIG;
> break;
> default:
> -   printf("ERROR: heap type not supported\n");
> +   heap_type_error_text();
> +   print_usage(argc, argv);
> exit(1);
> }
> break;
> @@ -82,8 +92,15 @@ int main(int argc, char *argv[])
> }
> }
>
> +   if (heap_type < 0) {
> +   heap_type_error_text();
> +   print_usage(argc, argv);
> +   exit(1);
> +   }
> +
> if (heap_size <= 0) {
> printf("heap_size cannot be 0\n");
> +   printf("  need to specify -s \n");
> print_usage(argc, argv);
> exit(1);
> }

I think both heap_type and heap_size error message is almost same.
How about creating a common error handler for both ?
Also it may be possible to merge both the above.
Or, another option is to make use of print_usage function itself,
instead of one more function.


> --
> 2.11.0
>

Re: [PATCH] selftests/android/ion: fix heap_type may be uninitialized

[Pintu Kumar]

On Thu, Mar 8, 2018 at 7:18 PM, Anders Roxell  wrote:
> gcc warns that 'heap_type' is not initialized if we don't come through
> any of the two 'case' statesments before:
>

OK thanks for your patch.

> ionapp_export.c:91:2: warning: ‘heap_type’ may be used uninitialized in
> this function [-Wmaybe-uninitialized]
>   printf("heap_type: %ld, heap_size: %ld\n", heap_type, heap_size);
>   ^~~~
>
> In the current code, we initialize the heap_type to -1 before the 'case'
> statements. We also change the print_usage function to state that
> heap_type and heap_size isn't optional, they are mandatory.
>

OK

> Fixes: 47a18c42d992 ("android/ion: userspace test utility for ion buffer 
> sharing")
> Signed-off-by: Anders Roxell 
> ---
>  .../testing/selftests/android/ion/ionapp_export.c  | 23 
> +++---
>  1 file changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/tools/testing/selftests/android/ion/ionapp_export.c 
> b/tools/testing/selftests/android/ion/ionapp_export.c
> index a944e72621a9..b42f803e9d2a 100644
> --- a/tools/testing/selftests/android/ion/ionapp_export.c
> +++ b/tools/testing/selftests/android/ion/ionapp_export.c
> @@ -31,16 +31,24 @@
>
>  void print_usage(int argc, char *argv[])
>  {
> -   printf("Usage: %s [-h ] [-i ] [-s ]\n",
> +   printf("Usage: %s [-h ] -i  -s \n",
> argv[0]);
>  }
>
> +void heap_type_error_text(void)
> +{
> +   printf("heap_type must be specified\n");
> +   printf("  need to specify -i \n");
> +   printf("  supported heap types 0 or 1\n");
> +}
> +

I think this error function needs to be generic.
See explanation below.


>  int main(int argc, char *argv[])
>  {
> int opt, ret, status, heapid;
> int sockfd, client_fd, shared_fd;
> unsigned char *map_buf;
> -   unsigned long map_len, heap_type, heap_size, flags;
> +   unsigned long map_len, heap_size, flags;
> +   long heap_type;
> struct ion_buffer_info info;
> struct socket_info skinfo;
>
> @@ -50,6 +58,7 @@ int main(int argc, char *argv[])
> }
>
> heap_size = 0;
> +   heap_type = -1;
> flags = 0;
>
> while ((opt = getopt(argc, argv, "hi:s:")) != -1) {
> @@ -68,7 +77,8 @@ int main(int argc, char *argv[])
> heap_type = ION_HEAP_TYPE_SYSTEM_CONTIG;
> break;
> default:
> -   printf("ERROR: heap type not supported\n");
> +   heap_type_error_text();
> +   print_usage(argc, argv);
> exit(1);
> }
> break;
> @@ -82,8 +92,15 @@ int main(int argc, char *argv[])
> }
> }
>
> +   if (heap_type < 0) {
> +   heap_type_error_text();
> +   print_usage(argc, argv);
> +   exit(1);
> +   }
> +
> if (heap_size <= 0) {
> printf("heap_size cannot be 0\n");
> +   printf("  need to specify -s \n");
> print_usage(argc, argv);
> exit(1);
> }

I think both heap_type and heap_size error message is almost same.
How about creating a common error handler for both ?
Also it may be possible to merge both the above.
Or, another option is to make use of print_usage function itself,
instead of one more function.


> --
> 2.11.0
>

Re: [VDSO]: vdso_test failing on arm 32 bit

[Pintu Kumar]

On Thu, Feb 8, 2018 at 9:41 PM, Lynch, Nathan <nathan_ly...@mentor.com> wrote:
>> I commented the device tree reading property:
>> arm,cpu-registers-not-fw-configured , from the arch/arm/kernel/vdso.c
>
> Don't do that, please. The presence of that property indicates that the 
> counter is not suitable for use by the OS. There is nothing we can do in 
> Linux to make the VDSO useful on this system; that is why it gets disabled at 
> runtime.
>
> The timing measurements you get are likely tainted by garbage results from 
> the VDSO itself.

OK thank you for your feedback.

But, we wanted to know, why vdso call timing is very high here. What
does this timing indicates?
gettimeofday: vdso: 4171 nsec/call

1) How to decide whether to enable or disable VDSO in the system, if
its not suitable.
Because in a VDSO enabled system, when we use gettimeofday API, we see
that its not falling back to the systemically, but may rather return a
garbage value from vdso itself.
If that is the case, shall we disable CONFIG_VDSO itself or keep it as it is ?

Please suggest your opinion.

2) Can you list down 1-2 arm 32-bit board, where VDSO can work perfectly ?

This will be really helpful for us to take some decision.


Thank You!
Pintu

Re: [VDSO]: vdso_test failing on arm 32 bit

[Pintu Kumar]

On Thu, Feb 8, 2018 at 9:41 PM, Lynch, Nathan  wrote:
>> I commented the device tree reading property:
>> arm,cpu-registers-not-fw-configured , from the arch/arm/kernel/vdso.c
>
> Don't do that, please. The presence of that property indicates that the 
> counter is not suitable for use by the OS. There is nothing we can do in 
> Linux to make the VDSO useful on this system; that is why it gets disabled at 
> runtime.
>
> The timing measurements you get are likely tainted by garbage results from 
> the VDSO itself.

OK thank you for your feedback.

But, we wanted to know, why vdso call timing is very high here. What
does this timing indicates?
gettimeofday: vdso: 4171 nsec/call

1) How to decide whether to enable or disable VDSO in the system, if
its not suitable.
Because in a VDSO enabled system, when we use gettimeofday API, we see
that its not falling back to the systemically, but may rather return a
garbage value from vdso itself.
If that is the case, shall we disable CONFIG_VDSO itself or keep it as it is ?

Please suggest your opinion.

2) Can you list down 1-2 arm 32-bit board, where VDSO can work perfectly ?

This will be really helpful for us to take some decision.


Thank You!
Pintu

Re: [VDSO]: vdso_test failing on arm 32 bit

[Pintu Kumar]

Dear Nathan & Russel,

I have few more question about vdso for arm-32-bit.

I am using iMX7 board to very VDSO gettimeofday timing.

To make kernel/Documentation/vDSO/vdsotest work on this board, I
commented the device tree reading property:
arm,cpu-registers-not-fw-configured , from the :
arch/arm/kernel/vdso.c
[However, I havent removed the property from device-tree itself, so it
is still being read by: drivers/clocksource/arm_arch_timer.c ⇒
arch_timer_of_init(…)]

But it seems the VDSO gettimeofday call is rather very slow.
This is the result of 10 iteration (with 10 seconds delay between
each), after fresh reboot:
bash-3.2# ./run_vdso.sh
The time is 1116.898864
===
The time is 1126.957507
===
The time is 1136.988507
===
The time is 1147.023134
===
The time is 1157.053017
===
The time is 1167.082912
===
The time is 1177.117722
===
The time is 1187.150945
===
The time is 1197.180820
===
The time is 1207.215339
===
The time is 1217.245189
===

Although architected timer support is not available in firmware, so it
may not give the accurate timing.

1) So, I wonder why vdso call is very slow and increasing by every second ?

This is the result of benchmark test.

bash-3.2# ./vdsotest_bench gettimeofday bench
gettimeofday: syscall: 681 nsec/call
gettimeofday: libc: 4190 nsec/call
gettimeofday: vdso: 4171 nsec/call

Also, when I call gettimeofday API from a sample program, I could not
find any system call trace.

bash-3.2# time ./test-vdso-syscall.out
real 0m3.997s
user 0m3.980s
sys 0m0.000s


2) So, how do I conclude whether VDSO gettimeofday is working correctly or not ?
3) Is it important to have that device-tree property in VDSO, if
arch-timer support is not available in firmware ?

Please let me know your opinion.


Thank You!
Pintu


On Thu, Dec 14, 2017 at 3:51 PM, Russell King - ARM Linux
<li...@armlinux.org.uk> wrote:
> On Thu, Dec 14, 2017 at 10:50:50AM +0530, Pintu Kumar wrote:
>> Oh ok. Thanks for this information.
>> So, in conclusion, can I summarize like this: VDSO support on ARM 32-bit
>> 1) VDSO works only on Cortex A7/A15 -> where generic timer extension
>> is available.
>> 2) VDSO works only on kernel 4.1 and above => where 32-bit vdso
>> support is available
>> 3) glibc version should be 2.20 or higher
>> 4) This device-tree property should not be set:
>> arm,cpu-registers-not-fw-configured => This means there is a firmware
>> bug
>>
>> Sorry, but still I have 2 more queries:
>> 1) Which is the firmware that we are talking about here ? What is the
>> name of firmware ? Is it available in kernel ?
>
> It's not in-kernel firmware, but whatever runs on the kernel prior to
> booting the kernel.
>
>> 2) Is there any ARM 32-bit board available, where I can confirm that
>> VDSO works on ARM 32-bit?
>
> I'm know of none.  That's not to say that there aren't any, I just don't
> know of any.
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
> According to speedtest.net: 8.21Mbps down 510kbps up

Re: [VDSO]: vdso_test failing on arm 32 bit

[Pintu Kumar]

Dear Nathan & Russel,

I have few more question about vdso for arm-32-bit.

I am using iMX7 board to very VDSO gettimeofday timing.

To make kernel/Documentation/vDSO/vdsotest work on this board, I
commented the device tree reading property:
arm,cpu-registers-not-fw-configured , from the :
arch/arm/kernel/vdso.c
[However, I havent removed the property from device-tree itself, so it
is still being read by: drivers/clocksource/arm_arch_timer.c ⇒
arch_timer_of_init(…)]

But it seems the VDSO gettimeofday call is rather very slow.
This is the result of 10 iteration (with 10 seconds delay between
each), after fresh reboot:
bash-3.2# ./run_vdso.sh
The time is 1116.898864
===
The time is 1126.957507
===
The time is 1136.988507
===
The time is 1147.023134
===
The time is 1157.053017
===
The time is 1167.082912
===
The time is 1177.117722
===
The time is 1187.150945
===
The time is 1197.180820
===
The time is 1207.215339
===
The time is 1217.245189
===

Although architected timer support is not available in firmware, so it
may not give the accurate timing.

1) So, I wonder why vdso call is very slow and increasing by every second ?

This is the result of benchmark test.

bash-3.2# ./vdsotest_bench gettimeofday bench
gettimeofday: syscall: 681 nsec/call
gettimeofday: libc: 4190 nsec/call
gettimeofday: vdso: 4171 nsec/call

Also, when I call gettimeofday API from a sample program, I could not
find any system call trace.

bash-3.2# time ./test-vdso-syscall.out
real 0m3.997s
user 0m3.980s
sys 0m0.000s


2) So, how do I conclude whether VDSO gettimeofday is working correctly or not ?
3) Is it important to have that device-tree property in VDSO, if
arch-timer support is not available in firmware ?

Please let me know your opinion.


Thank You!
Pintu


On Thu, Dec 14, 2017 at 3:51 PM, Russell King - ARM Linux
 wrote:
> On Thu, Dec 14, 2017 at 10:50:50AM +0530, Pintu Kumar wrote:
>> Oh ok. Thanks for this information.
>> So, in conclusion, can I summarize like this: VDSO support on ARM 32-bit
>> 1) VDSO works only on Cortex A7/A15 -> where generic timer extension
>> is available.
>> 2) VDSO works only on kernel 4.1 and above => where 32-bit vdso
>> support is available
>> 3) glibc version should be 2.20 or higher
>> 4) This device-tree property should not be set:
>> arm,cpu-registers-not-fw-configured => This means there is a firmware
>> bug
>>
>> Sorry, but still I have 2 more queries:
>> 1) Which is the firmware that we are talking about here ? What is the
>> name of firmware ? Is it available in kernel ?
>
> It's not in-kernel firmware, but whatever runs on the kernel prior to
> booting the kernel.
>
>> 2) Is there any ARM 32-bit board available, where I can confirm that
>> VDSO works on ARM 32-bit?
>
> I'm know of none.  That's not to say that there aren't any, I just don't
> know of any.
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
> According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCH] selftests/android: Fix line continuation in Makefile

[Pintu Kumar]

On Wed, Feb 7, 2018 at 5:22 AM, Daniel Díaz <daniel.d...@linaro.org> wrote:
> The Makefile lacks a couple of line continuation backslashes
> in an `if' clause, which can make the subsequent rsync
> command go awry over the whole filesystem (`rsync -a / /`).
>
>   /bin/sh: -c: line 5: syntax error: unexpected end of file
>   make[1]: [all] Error 1 (ignored)
>   TEST=$DIR"_test.sh"; \
>   if [ -e $DIR/$TEST ]; then
>   /bin/sh: -c: line 2: syntax error: unexpected end of file
>   make[1]: [all] Error 1 (ignored)
>   rsync -a $DIR/$TEST $BUILD_TARGET/;
>   [...a myriad of:]
>   [  rsync: readlink_stat("...") failed: Permission denied (13)]
>   [  skipping non-regular file "..."]
>   [  rsync: opendir "..." failed: Permission denied (13)]
>   [and many other errors...]
>   fi
>   make[1]: fi: Command not found
>   make[1]: [all] Error 127 (ignored)
>   done
>   make[1]: done: Command not found
>   make[1]: [all] Error 127 (ignored)
>
> Signed-off-by: Daniel Díaz <daniel.d...@linaro.org>
> ---
>  tools/testing/selftests/android/Makefile | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/tools/testing/selftests/android/Makefile 
> b/tools/testing/selftests/android/Makefile
> index 1a74922..f6304d2 100644
> --- a/tools/testing/selftests/android/Makefile
> +++ b/tools/testing/selftests/android/Makefile
> @@ -11,11 +11,11 @@ all:
> BUILD_TARGET=$(OUTPUT)/$$DIR;   \
> mkdir $$BUILD_TARGET  -p;   \
> make OUTPUT=$$BUILD_TARGET -C $$DIR $@;\
> -   #SUBDIR test prog name should be in the form: SUBDIR_test.sh
> +   #SUBDIR test prog name should be in the form: SUBDIR_test.sh \
> TEST=$$DIR"_test.sh"; \
> -   if [ -e $$DIR/$$TEST ]; then
> -   rsync -a $$DIR/$$TEST $$BUILD_TARGET/;
> -   fi
> +   if [ -e $$DIR/$$TEST ]; then \
> +   rsync -a $$DIR/$$TEST $$BUILD_TARGET/; \
> +   fi \
> done
>
>  override define RUN_TESTS

Acked-by: Pintu Agarwal <pintu.p...@gmail.com>

> --
> 2.7.4
>

Re: [PATCH] selftests/android: Fix line continuation in Makefile

[Pintu Kumar]

On Wed, Feb 7, 2018 at 5:22 AM, Daniel Díaz  wrote:
> The Makefile lacks a couple of line continuation backslashes
> in an `if' clause, which can make the subsequent rsync
> command go awry over the whole filesystem (`rsync -a / /`).
>
>   /bin/sh: -c: line 5: syntax error: unexpected end of file
>   make[1]: [all] Error 1 (ignored)
>   TEST=$DIR"_test.sh"; \
>   if [ -e $DIR/$TEST ]; then
>   /bin/sh: -c: line 2: syntax error: unexpected end of file
>   make[1]: [all] Error 1 (ignored)
>   rsync -a $DIR/$TEST $BUILD_TARGET/;
>   [...a myriad of:]
>   [  rsync: readlink_stat("...") failed: Permission denied (13)]
>   [  skipping non-regular file "..."]
>   [  rsync: opendir "..." failed: Permission denied (13)]
>   [and many other errors...]
>   fi
>   make[1]: fi: Command not found
>   make[1]: [all] Error 127 (ignored)
>   done
>   make[1]: done: Command not found
>   make[1]: [all] Error 127 (ignored)
>
> Signed-off-by: Daniel Díaz 
> ---
>  tools/testing/selftests/android/Makefile | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/tools/testing/selftests/android/Makefile 
> b/tools/testing/selftests/android/Makefile
> index 1a74922..f6304d2 100644
> --- a/tools/testing/selftests/android/Makefile
> +++ b/tools/testing/selftests/android/Makefile
> @@ -11,11 +11,11 @@ all:
> BUILD_TARGET=$(OUTPUT)/$$DIR;   \
> mkdir $$BUILD_TARGET  -p;   \
> make OUTPUT=$$BUILD_TARGET -C $$DIR $@;\
> -   #SUBDIR test prog name should be in the form: SUBDIR_test.sh
> +   #SUBDIR test prog name should be in the form: SUBDIR_test.sh \
> TEST=$$DIR"_test.sh"; \
> -   if [ -e $$DIR/$$TEST ]; then
> -   rsync -a $$DIR/$$TEST $$BUILD_TARGET/;
> -   fi
> +   if [ -e $$DIR/$$TEST ]; then \
> +   rsync -a $$DIR/$$TEST $$BUILD_TARGET/; \
> +   fi \
> done
>
>  override define RUN_TESTS

Acked-by: Pintu Agarwal 

> --
> 2.7.4
>

Re: [PATCH] selftests/android: Fix line continuation in Makefile

[Pintu Kumar]

On Wed, Feb 7, 2018 at 10:46 PM, Daniel Díaz Rodríguez
<daniel.d...@linaro.org> wrote:
> Hello!
>
>
> On 7 February 2018 at 00:01, Pintu Kumar <pintu.p...@gmail.com> wrote:
> [...]
>> Thanks for your patch.
>> However, I have copied this Makefile from
>> tools/testing/selftests/futex/Makefile before modifying it.
>> If there is a problem with backslash then the same problem must be
>> there in futex Makefile as well.
>
> There is. Patch coming.

OK

>
>
> [...]
>> Also is it because of make version ?
>> Can you check your make version ?
>
> It's make 3.81.

My make version was 4.1.
So I did not face any problem. I guess this problem is fixed from make
version 4.x on wards.
However, for backward compatibility we can include these change.

So, its looks good for me, however someone else must approve it.


>
> Thanks and greetings!
>
> Daniel Díaz
> daniel.d...@linaro.org

Re: [PATCH] selftests/android: Fix line continuation in Makefile

[Pintu Kumar]

On Wed, Feb 7, 2018 at 10:46 PM, Daniel Díaz Rodríguez
 wrote:
> Hello!
>
>
> On 7 February 2018 at 00:01, Pintu Kumar  wrote:
> [...]
>> Thanks for your patch.
>> However, I have copied this Makefile from
>> tools/testing/selftests/futex/Makefile before modifying it.
>> If there is a problem with backslash then the same problem must be
>> there in futex Makefile as well.
>
> There is. Patch coming.

OK

>
>
> [...]
>> Also is it because of make version ?
>> Can you check your make version ?
>
> It's make 3.81.

My make version was 4.1.
So I did not face any problem. I guess this problem is fixed from make
version 4.x on wards.
However, for backward compatibility we can include these change.

So, its looks good for me, however someone else must approve it.


>
> Thanks and greetings!
>
> Daniel Díaz
> daniel.d...@linaro.org

Re: [PATCH] selftests/android: Fix line continuation in Makefile

[Pintu Kumar]

On Wed, Feb 7, 2018 at 5:22 AM, Daniel Díaz <daniel.d...@linaro.org> wrote:
> The Makefile lacks a couple of line continuation backslashes
> in an `if' clause, which can make the subsequent rsync
> command go awry over the whole filesystem (`rsync -a / /`).
>
>   /bin/sh: -c: line 5: syntax error: unexpected end of file
>   make[1]: [all] Error 1 (ignored)
>   TEST=$DIR"_test.sh"; \
>   if [ -e $DIR/$TEST ]; then
>   /bin/sh: -c: line 2: syntax error: unexpected end of file
>   make[1]: [all] Error 1 (ignored)
>   rsync -a $DIR/$TEST $BUILD_TARGET/;
>   [...a myriad of:]
>   [  rsync: readlink_stat("...") failed: Permission denied (13)]
>   [  skipping non-regular file "..."]
>   [  rsync: opendir "..." failed: Permission denied (13)]
>   [and many other errors...]
>   fi
>   make[1]: fi: Command not found
>   make[1]: [all] Error 127 (ignored)
>   done
>   make[1]: done: Command not found
>   make[1]: [all] Error 127 (ignored)
>
> Signed-off-by: Daniel Díaz <daniel.d...@linaro.org>
> ---
>  tools/testing/selftests/android/Makefile | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/tools/testing/selftests/android/Makefile 
> b/tools/testing/selftests/android/Makefile
> index 1a74922..f6304d2 100644
> --- a/tools/testing/selftests/android/Makefile
> +++ b/tools/testing/selftests/android/Makefile
> @@ -11,11 +11,11 @@ all:
> BUILD_TARGET=$(OUTPUT)/$$DIR;   \
> mkdir $$BUILD_TARGET  -p;   \
> make OUTPUT=$$BUILD_TARGET -C $$DIR $@;\
> -   #SUBDIR test prog name should be in the form: SUBDIR_test.sh
> +   #SUBDIR test prog name should be in the form: SUBDIR_test.sh \
> TEST=$$DIR"_test.sh"; \
> -   if [ -e $$DIR/$$TEST ]; then
> -   rsync -a $$DIR/$$TEST $$BUILD_TARGET/;
> -   fi
> +   if [ -e $$DIR/$$TEST ]; then \
> +   rsync -a $$DIR/$$TEST $$BUILD_TARGET/; \
> +   fi \
> done

Thanks for your patch.
However, I have copied this Makefile from
tools/testing/selftests/futex/Makefile before modifying it.
If there is a problem with backslash then the same problem must be
there in futex Makefile as well.
Can you compare these 2 Makefile and see if there is any problem.

Also is it because of make version ?
Can you check your make version ?

Thank You!
Pintu

>
>  override define RUN_TESTS
> --
> 2.7.4
>

Re: [PATCH] selftests/android: Fix line continuation in Makefile

[Pintu Kumar]

On Wed, Feb 7, 2018 at 5:22 AM, Daniel Díaz  wrote:
> The Makefile lacks a couple of line continuation backslashes
> in an `if' clause, which can make the subsequent rsync
> command go awry over the whole filesystem (`rsync -a / /`).
>
>   /bin/sh: -c: line 5: syntax error: unexpected end of file
>   make[1]: [all] Error 1 (ignored)
>   TEST=$DIR"_test.sh"; \
>   if [ -e $DIR/$TEST ]; then
>   /bin/sh: -c: line 2: syntax error: unexpected end of file
>   make[1]: [all] Error 1 (ignored)
>   rsync -a $DIR/$TEST $BUILD_TARGET/;
>   [...a myriad of:]
>   [  rsync: readlink_stat("...") failed: Permission denied (13)]
>   [  skipping non-regular file "..."]
>   [  rsync: opendir "..." failed: Permission denied (13)]
>   [and many other errors...]
>   fi
>   make[1]: fi: Command not found
>   make[1]: [all] Error 127 (ignored)
>   done
>   make[1]: done: Command not found
>   make[1]: [all] Error 127 (ignored)
>
> Signed-off-by: Daniel Díaz 
> ---
>  tools/testing/selftests/android/Makefile | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/tools/testing/selftests/android/Makefile 
> b/tools/testing/selftests/android/Makefile
> index 1a74922..f6304d2 100644
> --- a/tools/testing/selftests/android/Makefile
> +++ b/tools/testing/selftests/android/Makefile
> @@ -11,11 +11,11 @@ all:
> BUILD_TARGET=$(OUTPUT)/$$DIR;   \
> mkdir $$BUILD_TARGET  -p;   \
> make OUTPUT=$$BUILD_TARGET -C $$DIR $@;\
> -   #SUBDIR test prog name should be in the form: SUBDIR_test.sh
> +   #SUBDIR test prog name should be in the form: SUBDIR_test.sh \
> TEST=$$DIR"_test.sh"; \
> -   if [ -e $$DIR/$$TEST ]; then
> -   rsync -a $$DIR/$$TEST $$BUILD_TARGET/;
> -   fi
> +   if [ -e $$DIR/$$TEST ]; then \
> +   rsync -a $$DIR/$$TEST $$BUILD_TARGET/; \
> +   fi \
> done

Thanks for your patch.
However, I have copied this Makefile from
tools/testing/selftests/futex/Makefile before modifying it.
If there is a problem with backslash then the same problem must be
there in futex Makefile as well.
Can you compare these 2 Makefile and see if there is any problem.

Also is it because of make version ?
Can you check your make version ?

Thank You!
Pintu

>
>  override define RUN_TESTS
> --
> 2.7.4
>

Re: [perf] perf test BPF fails on 4.9.20

[Pintu Kumar]

On Mon, Feb 5, 2018 at 7:24 PM, Masami Hiramatsu <mhira...@kernel.org> wrote:
> On Mon, 5 Feb 2018 15:17:41 +0530
> Pintu Kumar <pintu.p...@gmail.com> wrote:
>
>> On Sat, Feb 3, 2018 at 6:49 PM, Masami Hiramatsu <mhira...@kernel.org> wrote:
>> > Hi Pintu,
>> >
>> > On Fri, 2 Feb 2018 19:03:30 +0530
>> > Pintu Kumar <pintu.p...@gmail.com> wrote:
>> >
>> >> Hi All,
>> >>
>> >> I have fixed both the issue with perf test.
>> >>
>> >> 1) 16: Try 'import perf' in python, checking link problems  : FAILED!
>> >> To fix this issue, I have to install:
>> >> pip install --upgrade pip
>> >> pip2.7 install perf
>> >>
>> >> 2) 37.2: Test BPF prologue generation   : FAILED!
>> >> To fix this issue I had to enable full version of CONFIG_DEBUG_INFO in 
>> >> kernel.
>> >>
>> >> Now, my question is:
>> >> Is it possible to pass BPF test without enabling CONFIG_DEBUG_INFO in 
>> >> kernel ?
>> >
>> > It depends on what BPF test does, but it seems to access local vars. This 
>> > means
>> > you need to enable CONFIG_DEBUG_INFO. With debuginfo we can find the 
>> > assignment
>> > of register/stack for each local variable.
>> >
>>
>> OK. Thank you so much for your reply.
>> I think we don't need BPF test at this time.
>> Is it possible to disable/skip it ?
>
> It depends on what you want to do with perf. If you don't use BPF, yes, you 
> can
> skip it :)
>

Yes I want to skip the BPF.
What is the best way to skip it.

I found out that by commenting 'bpf' under :
tools/build/Makefile.feature -> FEATURE_TESTS_BASIC,
I can turn BPF feature OFF during compilation.
However, I still need to execute BPF test and check, if it skips.

Is this good enough ?




> Thank you,
>
> --
> Masami Hiramatsu <mhira...@kernel.org>

Re: [perf] perf test BPF fails on 4.9.20

[Pintu Kumar]

On Mon, Feb 5, 2018 at 7:24 PM, Masami Hiramatsu  wrote:
> On Mon, 5 Feb 2018 15:17:41 +0530
> Pintu Kumar  wrote:
>
>> On Sat, Feb 3, 2018 at 6:49 PM, Masami Hiramatsu  wrote:
>> > Hi Pintu,
>> >
>> > On Fri, 2 Feb 2018 19:03:30 +0530
>> > Pintu Kumar  wrote:
>> >
>> >> Hi All,
>> >>
>> >> I have fixed both the issue with perf test.
>> >>
>> >> 1) 16: Try 'import perf' in python, checking link problems  : FAILED!
>> >> To fix this issue, I have to install:
>> >> pip install --upgrade pip
>> >> pip2.7 install perf
>> >>
>> >> 2) 37.2: Test BPF prologue generation   : FAILED!
>> >> To fix this issue I had to enable full version of CONFIG_DEBUG_INFO in 
>> >> kernel.
>> >>
>> >> Now, my question is:
>> >> Is it possible to pass BPF test without enabling CONFIG_DEBUG_INFO in 
>> >> kernel ?
>> >
>> > It depends on what BPF test does, but it seems to access local vars. This 
>> > means
>> > you need to enable CONFIG_DEBUG_INFO. With debuginfo we can find the 
>> > assignment
>> > of register/stack for each local variable.
>> >
>>
>> OK. Thank you so much for your reply.
>> I think we don't need BPF test at this time.
>> Is it possible to disable/skip it ?
>
> It depends on what you want to do with perf. If you don't use BPF, yes, you 
> can
> skip it :)
>

Yes I want to skip the BPF.
What is the best way to skip it.

I found out that by commenting 'bpf' under :
tools/build/Makefile.feature -> FEATURE_TESTS_BASIC,
I can turn BPF feature OFF during compilation.
However, I still need to execute BPF test and check, if it skips.

Is this good enough ?




> Thank you,
>
> --
> Masami Hiramatsu 

Re: [perf] perf test BPF fails on 4.9.20

[Pintu Kumar]

On Sat, Feb 3, 2018 at 6:49 PM, Masami Hiramatsu <mhira...@kernel.org> wrote:
> Hi Pintu,
>
> On Fri, 2 Feb 2018 19:03:30 +0530
> Pintu Kumar <pintu.p...@gmail.com> wrote:
>
>> Hi All,
>>
>> I have fixed both the issue with perf test.
>>
>> 1) 16: Try 'import perf' in python, checking link problems  : FAILED!
>> To fix this issue, I have to install:
>> pip install --upgrade pip
>> pip2.7 install perf
>>
>> 2) 37.2: Test BPF prologue generation   : FAILED!
>> To fix this issue I had to enable full version of CONFIG_DEBUG_INFO in 
>> kernel.
>>
>> Now, my question is:
>> Is it possible to pass BPF test without enabling CONFIG_DEBUG_INFO in kernel 
>> ?
>
> It depends on what BPF test does, but it seems to access local vars. This 
> means
> you need to enable CONFIG_DEBUG_INFO. With debuginfo we can find the 
> assignment
> of register/stack for each local variable.
>

OK. Thank you so much for your reply.
I think we don't need BPF test at this time.
Is it possible to disable/skip it ?


> Thank you,
>>
>>
>> Thanks,
>> Pintu
>>
>>
>> On Fri, Feb 2, 2018 at 1:25 PM, Pintu Kumar <pintu.p...@gmail.com> wrote:
>> > Hi,
>> >
>> > perf test bpf prologue generation is failing.
>> > 37.2: Test BPF prologue generation   : FAILED!
>> >
>> > Try to find probe point from debuginfo.
>> > Matched function: null_lseek [105be32]
>> > Probe point found: null_lseek+0
>> > Searching 'file' variable in context.
>> > Converting variable file into trace event.
>> > converting f_mode in file
>> > file(type:file) has no member f_mode.
>> > An error occurred in debuginfo analysis (-22).
>> > bpf_probe: failed to convert perf probe eventsFailed to add events
>> > selected by BPF
>> > test child finished with -1
>> >  end 
>> > Test BPF filter subtest 1: FAILED!
>> >
>> >
>> > Is there any fix available for this issue?
>> > I searched 4.15, but could not relate any of the patches to this.
>> >
>> >
>> > Thanks,
>> > Pintu
>> >
>> >
>> >
>> > On Thu, Feb 1, 2018 at 7:34 PM, Pintu Kumar <pintu.p...@gmail.com> wrote:
>> >> Hi,
>> >>
>> >> After enabling DEBUG_INFO in kernel I still get this error for BPF test.
>> >> Please help.
>> >>
>> >> # perf test BPF -v
>> >> .
>> >> Looking at the vmlinux_path (8 entries long)
>> >> Using 
>> >> /usr/lib/debug/boot/vmlinux-4.9.00--amd-x86-64-00071-gd94c220-dirty
>> >> for symbols
>> >> Open Debuginfo file:
>> >> /usr/lib/debug/boot/vmlinux-4.9.00--amd-x86-64-00071-gd94c220-dirty
>> >> Try to find probe point from debuginfo.
>> >> Matched function: null_lseek [105be32]
>> >> Probe point found: null_lseek+0
>> >> Searching 'file' variable in context.
>> >> Converting variable file into trace event.
>> >> converting f_mode in file
>> >> file(type:file) has no member f_mode.
>> >> An error occurred in debuginfo analysis (-22).
>> >> bpf_probe: failed to convert perf probe eventsFailed to add events
>> >> selected by BPF
>> >> test child finished with -1
>> >>  end 
>> >> Test BPF filter subtest 1: FAILED!
>> >>
>> >>
>> >>
>> >> On Thu, Feb 1, 2018 at 10:50 AM, Pintu Kumar <pintu.p...@gmail.com> wrote:
>> >>> Dear Masami,
>> >>>
>> >>> Now I am stuck again with 'perf test' failure on 4.9
>> >>>
>> >>> # perf --version
>> >>> perf version 4.9.20-
>> >>>
>> >>> # perf test
>> >>> 16: Try 'import perf' in python, checking link problems  : FAILED!
>> >>> 37.2: Test BPF prologue generation   : FAILED!
>> >>>
>> >>> If you have any clue about these failure please hep me.
>> >>>
>> >>> Here are the verbose output:
>> >>> -
>> >>> 1) # perf test python -v
>> >>> 16: Try 'import perf' in python, checking link problems  :
>> >>> --- start ---
>> >>> test child forked, pid 24562
>> >>> Traceback (most rece

Re: [perf] perf test BPF fails on 4.9.20

[Pintu Kumar]

On Sat, Feb 3, 2018 at 6:49 PM, Masami Hiramatsu  wrote:
> Hi Pintu,
>
> On Fri, 2 Feb 2018 19:03:30 +0530
> Pintu Kumar  wrote:
>
>> Hi All,
>>
>> I have fixed both the issue with perf test.
>>
>> 1) 16: Try 'import perf' in python, checking link problems  : FAILED!
>> To fix this issue, I have to install:
>> pip install --upgrade pip
>> pip2.7 install perf
>>
>> 2) 37.2: Test BPF prologue generation   : FAILED!
>> To fix this issue I had to enable full version of CONFIG_DEBUG_INFO in 
>> kernel.
>>
>> Now, my question is:
>> Is it possible to pass BPF test without enabling CONFIG_DEBUG_INFO in kernel 
>> ?
>
> It depends on what BPF test does, but it seems to access local vars. This 
> means
> you need to enable CONFIG_DEBUG_INFO. With debuginfo we can find the 
> assignment
> of register/stack for each local variable.
>

OK. Thank you so much for your reply.
I think we don't need BPF test at this time.
Is it possible to disable/skip it ?


> Thank you,
>>
>>
>> Thanks,
>> Pintu
>>
>>
>> On Fri, Feb 2, 2018 at 1:25 PM, Pintu Kumar  wrote:
>> > Hi,
>> >
>> > perf test bpf prologue generation is failing.
>> > 37.2: Test BPF prologue generation   : FAILED!
>> >
>> > Try to find probe point from debuginfo.
>> > Matched function: null_lseek [105be32]
>> > Probe point found: null_lseek+0
>> > Searching 'file' variable in context.
>> > Converting variable file into trace event.
>> > converting f_mode in file
>> > file(type:file) has no member f_mode.
>> > An error occurred in debuginfo analysis (-22).
>> > bpf_probe: failed to convert perf probe eventsFailed to add events
>> > selected by BPF
>> > test child finished with -1
>> >  end 
>> > Test BPF filter subtest 1: FAILED!
>> >
>> >
>> > Is there any fix available for this issue?
>> > I searched 4.15, but could not relate any of the patches to this.
>> >
>> >
>> > Thanks,
>> > Pintu
>> >
>> >
>> >
>> > On Thu, Feb 1, 2018 at 7:34 PM, Pintu Kumar  wrote:
>> >> Hi,
>> >>
>> >> After enabling DEBUG_INFO in kernel I still get this error for BPF test.
>> >> Please help.
>> >>
>> >> # perf test BPF -v
>> >> .
>> >> Looking at the vmlinux_path (8 entries long)
>> >> Using 
>> >> /usr/lib/debug/boot/vmlinux-4.9.00--amd-x86-64-00071-gd94c220-dirty
>> >> for symbols
>> >> Open Debuginfo file:
>> >> /usr/lib/debug/boot/vmlinux-4.9.00--amd-x86-64-00071-gd94c220-dirty
>> >> Try to find probe point from debuginfo.
>> >> Matched function: null_lseek [105be32]
>> >> Probe point found: null_lseek+0
>> >> Searching 'file' variable in context.
>> >> Converting variable file into trace event.
>> >> converting f_mode in file
>> >> file(type:file) has no member f_mode.
>> >> An error occurred in debuginfo analysis (-22).
>> >> bpf_probe: failed to convert perf probe eventsFailed to add events
>> >> selected by BPF
>> >> test child finished with -1
>> >>  end 
>> >> Test BPF filter subtest 1: FAILED!
>> >>
>> >>
>> >>
>> >> On Thu, Feb 1, 2018 at 10:50 AM, Pintu Kumar  wrote:
>> >>> Dear Masami,
>> >>>
>> >>> Now I am stuck again with 'perf test' failure on 4.9
>> >>>
>> >>> # perf --version
>> >>> perf version 4.9.20-
>> >>>
>> >>> # perf test
>> >>> 16: Try 'import perf' in python, checking link problems  : FAILED!
>> >>> 37.2: Test BPF prologue generation   : FAILED!
>> >>>
>> >>> If you have any clue about these failure please hep me.
>> >>>
>> >>> Here are the verbose output:
>> >>> -
>> >>> 1) # perf test python -v
>> >>> 16: Try 'import perf' in python, checking link problems  :
>> >>> --- start ---
>> >>> test child forked, pid 24562
>> >>> Traceback (most recent call last):
>> >>>   File "", line 1, in 
>> >>> ImportError: No module named p

Re: [perf] perf test BPF fails on 4.9.20

[Pintu Kumar]

Hi All,

I have fixed both the issue with perf test.

1) 16: Try 'import perf' in python, checking link problems  : FAILED!
To fix this issue, I have to install:
pip install --upgrade pip
pip2.7 install perf

2) 37.2: Test BPF prologue generation   : FAILED!
To fix this issue I had to enable full version of CONFIG_DEBUG_INFO in kernel.

Now, my question is:
Is it possible to pass BPF test without enabling CONFIG_DEBUG_INFO in kernel ?


Thanks,
Pintu


On Fri, Feb 2, 2018 at 1:25 PM, Pintu Kumar <pintu.p...@gmail.com> wrote:
> Hi,
>
> perf test bpf prologue generation is failing.
> 37.2: Test BPF prologue generation   : FAILED!
>
> Try to find probe point from debuginfo.
> Matched function: null_lseek [105be32]
> Probe point found: null_lseek+0
> Searching 'file' variable in context.
> Converting variable file into trace event.
> converting f_mode in file
> file(type:file) has no member f_mode.
> An error occurred in debuginfo analysis (-22).
> bpf_probe: failed to convert perf probe eventsFailed to add events
> selected by BPF
> test child finished with -1
>  end 
> Test BPF filter subtest 1: FAILED!
>
>
> Is there any fix available for this issue?
> I searched 4.15, but could not relate any of the patches to this.
>
>
> Thanks,
> Pintu
>
>
>
> On Thu, Feb 1, 2018 at 7:34 PM, Pintu Kumar <pintu.p...@gmail.com> wrote:
>> Hi,
>>
>> After enabling DEBUG_INFO in kernel I still get this error for BPF test.
>> Please help.
>>
>> # perf test BPF -v
>> .
>> Looking at the vmlinux_path (8 entries long)
>> Using /usr/lib/debug/boot/vmlinux-4.9.00--amd-x86-64-00071-gd94c220-dirty
>> for symbols
>> Open Debuginfo file:
>> /usr/lib/debug/boot/vmlinux-4.9.00--amd-x86-64-00071-gd94c220-dirty
>> Try to find probe point from debuginfo.
>> Matched function: null_lseek [105be32]
>> Probe point found: null_lseek+0
>> Searching 'file' variable in context.
>> Converting variable file into trace event.
>> converting f_mode in file
>> file(type:file) has no member f_mode.
>> An error occurred in debuginfo analysis (-22).
>> bpf_probe: failed to convert perf probe eventsFailed to add events
>> selected by BPF
>> test child finished with -1
>>  end 
>> Test BPF filter subtest 1: FAILED!
>>
>>
>>
>> On Thu, Feb 1, 2018 at 10:50 AM, Pintu Kumar <pintu.p...@gmail.com> wrote:
>>> Dear Masami,
>>>
>>> Now I am stuck again with 'perf test' failure on 4.9
>>>
>>> # perf --version
>>> perf version 4.9.20-
>>>
>>> # perf test
>>> 16: Try 'import perf' in python, checking link problems  : FAILED!
>>> 37.2: Test BPF prologue generation   : FAILED!
>>>
>>> If you have any clue about these failure please hep me.
>>>
>>> Here are the verbose output:
>>> -
>>> 1) # perf test python -v
>>> 16: Try 'import perf' in python, checking link problems  :
>>> --- start ---
>>> test child forked, pid 24562
>>> Traceback (most recent call last):
>>>   File "", line 1, in 
>>> ImportError: No module named perf
>>> test child finished with -1
>>>  end 
>>> Try 'import perf' in python, checking link problems: FAILED!
>>> --
>>>
>>> 2) # perf test BPF -v
>>> ---
>>> .
>>> bpf: config 'func=null_lseek file->f_mode offset orig' is ok
>>> Looking at the vmlinux_path (8 entries long)
>>> symsrc__init: cannot get elf header.
>>> Failed to find the path for kernel: Invalid ELF file
>>> bpf_probe: failed to convert perf probe eventsFailed to add events
>>> selected by BPF
>>> test child finished with -1
>>>  end 
>>> Test BPF filter subtest 1: FAILED!
>>>
>>> ---
>>>
>>>
>>> Thanks,
>>> Pintu
>>>
>>>
>>> On Wed, Jan 31, 2018 at 9:01 AM, Masami Hiramatsu <mhira...@kernel.org> 
>>> wrote:
>>>> On Tue, 30 Jan 2018 19:20:36 +0530
>>>> Pintu Kumar <pintu.p...@gmail.com> wrote:
>>>>
>>>>> On Tue, Jan 30, 2018 at 11:13 AM, Masami Hiramatsu <mhira...@kernel.or

Re: [perf] perf test BPF fails on 4.9.20

[Pintu Kumar]

Hi All,

I have fixed both the issue with perf test.

1) 16: Try 'import perf' in python, checking link problems  : FAILED!
To fix this issue, I have to install:
pip install --upgrade pip
pip2.7 install perf

2) 37.2: Test BPF prologue generation   : FAILED!
To fix this issue I had to enable full version of CONFIG_DEBUG_INFO in kernel.

Now, my question is:
Is it possible to pass BPF test without enabling CONFIG_DEBUG_INFO in kernel ?


Thanks,
Pintu


On Fri, Feb 2, 2018 at 1:25 PM, Pintu Kumar  wrote:
> Hi,
>
> perf test bpf prologue generation is failing.
> 37.2: Test BPF prologue generation   : FAILED!
>
> Try to find probe point from debuginfo.
> Matched function: null_lseek [105be32]
> Probe point found: null_lseek+0
> Searching 'file' variable in context.
> Converting variable file into trace event.
> converting f_mode in file
> file(type:file) has no member f_mode.
> An error occurred in debuginfo analysis (-22).
> bpf_probe: failed to convert perf probe eventsFailed to add events
> selected by BPF
> test child finished with -1
>  end 
> Test BPF filter subtest 1: FAILED!
>
>
> Is there any fix available for this issue?
> I searched 4.15, but could not relate any of the patches to this.
>
>
> Thanks,
> Pintu
>
>
>
> On Thu, Feb 1, 2018 at 7:34 PM, Pintu Kumar  wrote:
>> Hi,
>>
>> After enabling DEBUG_INFO in kernel I still get this error for BPF test.
>> Please help.
>>
>> # perf test BPF -v
>> .
>> Looking at the vmlinux_path (8 entries long)
>> Using /usr/lib/debug/boot/vmlinux-4.9.00--amd-x86-64-00071-gd94c220-dirty
>> for symbols
>> Open Debuginfo file:
>> /usr/lib/debug/boot/vmlinux-4.9.00--amd-x86-64-00071-gd94c220-dirty
>> Try to find probe point from debuginfo.
>> Matched function: null_lseek [105be32]
>> Probe point found: null_lseek+0
>> Searching 'file' variable in context.
>> Converting variable file into trace event.
>> converting f_mode in file
>> file(type:file) has no member f_mode.
>> An error occurred in debuginfo analysis (-22).
>> bpf_probe: failed to convert perf probe eventsFailed to add events
>> selected by BPF
>> test child finished with -1
>>  end 
>> Test BPF filter subtest 1: FAILED!
>>
>>
>>
>> On Thu, Feb 1, 2018 at 10:50 AM, Pintu Kumar  wrote:
>>> Dear Masami,
>>>
>>> Now I am stuck again with 'perf test' failure on 4.9
>>>
>>> # perf --version
>>> perf version 4.9.20-
>>>
>>> # perf test
>>> 16: Try 'import perf' in python, checking link problems  : FAILED!
>>> 37.2: Test BPF prologue generation   : FAILED!
>>>
>>> If you have any clue about these failure please hep me.
>>>
>>> Here are the verbose output:
>>> -
>>> 1) # perf test python -v
>>> 16: Try 'import perf' in python, checking link problems  :
>>> --- start ---
>>> test child forked, pid 24562
>>> Traceback (most recent call last):
>>>   File "", line 1, in 
>>> ImportError: No module named perf
>>> test child finished with -1
>>>  end 
>>> Try 'import perf' in python, checking link problems: FAILED!
>>> --
>>>
>>> 2) # perf test BPF -v
>>> -------
>>> .
>>> bpf: config 'func=null_lseek file->f_mode offset orig' is ok
>>> Looking at the vmlinux_path (8 entries long)
>>> symsrc__init: cannot get elf header.
>>> Failed to find the path for kernel: Invalid ELF file
>>> bpf_probe: failed to convert perf probe eventsFailed to add events
>>> selected by BPF
>>> test child finished with -1
>>>  end 
>>> Test BPF filter subtest 1: FAILED!
>>>
>>> ---
>>>
>>>
>>> Thanks,
>>> Pintu
>>>
>>>
>>> On Wed, Jan 31, 2018 at 9:01 AM, Masami Hiramatsu  
>>> wrote:
>>>> On Tue, 30 Jan 2018 19:20:36 +0530
>>>> Pintu Kumar  wrote:
>>>>
>>>>> On Tue, Jan 30, 2018 at 11:13 AM, Masami Hiramatsu  
>>>>> wrote:
>>>>> >
>>>>> > On Mon, 29 Jan 2018 22:00:52 +0530
>>>>> > Pint