linux.kernel - 26 new messages in 9 topics - digest

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

linux.kernel@googlegroups.com

Today's topics:

* perf ui/tui: Add support for showing relative percentage - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/a2b106be220a1f65?hl=en
* perf on raspberry-pi without overflow interrupt - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a41a2323b165e1d8?hl=en
* linux-next: manual merge of the tip tree with the net-next tree - 3 messages,
3 authors
http://groups.google.com/group/linux.kernel/t/ec246d2e3d0c7bcd?hl=en
* linux-next: manual merge of the akpm-current tree with the tip tree - 2
messages, 2 authors
http://groups.google.com/group/linux.kernel/t/dbed449ea85f37ac?hl=en
* linux-next: manual merge of the akpm-current tree with the char-misc tree -
1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/1cff4bcb8a419506?hl=en
* mm/zswap: Check all pool pages instead of one pool pages - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/81cd07f00a212f3a?hl=en
* staging: ced1401: Fix dev_<level> messages - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/cf0ebd61b1e13adb?hl=en
* net_dma: revert 'copied_early' - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f63a9d0143e0c240?hl=en
* perf tools: Enable --children option by default - 14 messages, 1 author
http://groups.google.com/group/linux.kernel/t/eb1147ab9c3d80ab?hl=en

==============================================================================
TOPIC: perf ui/tui: Add support for showing relative percentage
http://groups.google.com/group/linux.kernel/t/a2b106be220a1f65?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 13 2014 8:50 pm
From: Namhyung Kim


When filtering by thread, dso or symbol on TUI it also update total
period so that the output shows different result than no filter - the
percentage changed to relative to filtered entries only. Sometimes
(always?) this is not desired since users might expect same results
with filter.

So change this behavior depends on symbol_conf.filter_relative value.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
---
tools/perf/util/hist.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 2d81f3aefad0..58c799d9b689 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -696,10 +696,11 @@ static void hists__remove_entry_filter(struct hists *hists, struct hist_entry *h
return;

++hists->nr_entries;
+ if (symbol_conf.filter_relative)
+ hists->stats.total_period += h->stat.period;
if (h->ms.unfolded)
hists->nr_entries += h->nr_rows;
h->row_offset = 0;
- hists->stats.total_period += h->stat.period;
hists->stats.nr_events[PERF_RECORD_SAMPLE] += h->stat.nr_events;

hists__calc_col_len(hists, h);
@@ -722,7 +723,9 @@ void hists__filter_by_dso(struct hists *hists)
{
struct rb_node *nd;

- hists->nr_entries = hists->stats.total_period = 0;
+ hists->nr_entries = 0;
+ if (symbol_conf.filter_relative)
+ hists->stats.total_period = 0;
hists->stats.nr_events[PERF_RECORD_SAMPLE] = 0;
hists__reset_col_len(hists);

@@ -755,7 +758,9 @@ void hists__filter_by_thread(struct hists *hists)
{
struct rb_node *nd;

- hists->nr_entries = hists->stats.total_period = 0;
+ hists->nr_entries = 0;
+ if (symbol_conf.filter_relative)
+ hists->stats.total_period = 0;
hists->stats.nr_events[PERF_RECORD_SAMPLE] = 0;
hists__reset_col_len(hists);

@@ -786,7 +791,9 @@ void hists__filter_by_symbol(struct hists *hists)
{
struct rb_node *nd;

- hists->nr_entries = hists->stats.total_period = 0;
+ hists->nr_entries = 0;
+ if (symbol_conf.filter_relative)
+ hists->stats.total_period = 0;
hists->stats.nr_events[PERF_RECORD_SAMPLE] = 0;
hists__reset_col_len(hists);

--
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: perf on raspberry-pi without overflow interrupt
http://groups.google.com/group/linux.kernel/t/a41a2323b165e1d8?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Jan 13 2014 8:50 pm
From: Vince Weaver


On Fri, 10 Jan 2014, Will Deacon wrote:

> In the absence of a core change, I think I'd rather have something like your
> second patch, but without the extra no_overflow_irq field (you can check the
> platform device, as I mentioned previously).

Something like the following? It works on my rasp-pi, still waiting for
the compile to finish on the pandaboard so I haven't verified that the
has-working-interrupt case still works.

---

Allow hardware perf_events to be enabled even if no overflow
interrupt is available. Return EOPNOTSUPP if a sampling event
is attempted and the interrupt is not available.

This is necessary for access to hardware perf_events on
the Raspberry-Pi (bcm2835).

Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>

diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index bc3f2ef..e2c4aa2 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -397,7 +397,7 @@ __hw_perf_event_init(struct perf_event *event)
*/
hwc->config_base |= (unsigned long)mapping;

- if (!hwc->sample_period) {
+ if (!is_sampling_event(event)) {
/*
* For non-sampling runs, limit the sample_period to half
* of the counter width. That way, the new counter value
@@ -407,6 +407,14 @@ __hw_perf_event_init(struct perf_event *event)
hwc->sample_period = armpmu->max_period >> 1;
hwc->last_period = hwc->sample_period;
local64_set(&hwc->period_left, hwc->sample_period);
+ } else {
+
+ /*
+ * If we have no PMU interrupt we cannot sample.
+ */
+ if (platform_get_irq(armpmu->plat_device, 0) < 0)
+ return -EOPNOTSUPP;
+
}

if (event->group_leader != event) {
diff --git a/arch/arm/kernel/perf_event_cpu.c b/arch/arm/kernel/perf_event_cpu.c
index d85055c..7a84738 100644
--- a/arch/arm/kernel/perf_event_cpu.c
+++ b/arch/arm/kernel/perf_event_cpu.c
@@ -97,8 +97,8 @@ static int cpu_pmu_request_irq(struct arm_pmu *cpu_pmu, irq_handler_t handler)

irqs = min(pmu_device->num_resources, num_possible_cpus());
if (irqs < 1) {
- pr_err("no irqs for PMUs defined\n");
- return -ENODEV;
+ printk_once("no irqs for PMUs defined, sampled events not supported\n");
+ return 0;
}

for (i = 0; i < irqs; ++i) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 2 of 2 ==
Date: Mon, Jan 13 2014 9:00 pm
From: Vince Weaver


On Fri, 10 Jan 2014, Peter Zijlstra wrote:

> On Thu, Jan 09, 2014 at 11:08:47PM -0500, Vince Weaver wrote:
> > On Thu, 9 Jan 2014, Will Deacon wrote:
> >
> > > I'd rather see it in the generic code if at all possible. Maybe we could add
> > > a flags field to perf_pmu_register?
> >
> > I can look into adding the check in generic code.
>
> Adding something like this to the generic code would mean adding a
> struct pmu capabilities field and visiting all existing PMU
> implementations to properly fill this out.

I don't see an existing pmu capabilities struct... or do you mean
coming up with one?

Would it only hold an "overflow_interrupt_available" flag, or are
there other generic capabilities it would be handy to know about?

> There's a number of hardware PMU implementations that do not have an
> interrupt and would need to set this flag.

Well that can be added gradually, right? Things wouldn't get any worse if
we add a generic check without auditing all code, things will just behave
the same as before for those architectures.

There is some subtlety here though. On ARM (or at least rasp-pi) the
overflow hardware is there, just no interrupt is hooked up. So things
like counter overflow are handled as long as overflows aren't faster than
context switch time. It's just sampled events aren't possible.

On architectures without overflow support at all (I've had such hardware;
some SPARC machines, the Playstation 3 hypervisor) then counter overflow
isn't possible without a periodic timer (sort of like what is done with
Intel uncore). Is that something that should be in generic code too?

Vince
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: linux-next: manual merge of the tip tree with the net-next tree
http://groups.google.com/group/linux.kernel/t/ec246d2e3d0c7bcd?hl=en
==============================================================================

== 1 of 3 ==
Date: Mon, Jan 13 2014 9:00 pm
From: "H. Peter Anvin"


On 01/13/2014 07:02 PM, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 13 Jan 2014 14:20:59 +1100 Stephen Rothwell
> <sfr@canb.auug.org.au> wrote:
>>
>> On Mon, 13 Jan 2014 14:18:24 +1100 Stephen Rothwell
>> <sfr@canb.auug.org.au> wrote:
>>>
>>> Today's linux-next merge of the tip tree got conflicts in
>>> arch/arc/include/asm/Kbuild, arch/cris/include/asm/Kbuild,
>>> arch/hexagon/include/asm/Kbuild,
>>> arch/microblaze/include/asm/Kbuild,
>>> arch/parisc/include/asm/Kbuild and
>>> arch/score/include/asm/Kbuild between commit e3fec2f74f7f
>>> ("lib: Add missing arch generic-y entries for
>>> asm-generic/hash.h") from the net-next tree and commit
>>> 93ea02bb8435 ("arch: Clean up asm/barrier.h implementations
>>> using asm-generic/barrier.h") from the tip tree.
>>>
>>> I fixed it up (see below) and can carry the fix as necessary
>>> (no action is required).
>>>
>>> BTW: thanks for not keeping the Kbuild files sorted :-(
>>
>> I missed arch/mn10300/include/asm/Kbuild the first time round.
>
> And ... git rerere does not work well here. It stores resolutions
> by a hash of the (sanitised) conflict and since most of these files
> have exactly the same conflict, I am going to have to edit 5 of
> them by hand every day.
>

Well, you probably can keep a diff from the conflict-merge tree to the
fix, but still.

Is there a sensible way we can fix this in either net-next or tip?

-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 2 of 3 ==
Date: Mon, Jan 13 2014 9:20 pm
From: Stephen Rothwell


Hi,

On Mon, 13 Jan 2014 20:51:43 -0800 "H. Peter Anvin" <hpa@zytor.com> wrote:
>
> On 01/13/2014 07:02 PM, Stephen Rothwell wrote:
> >
> > On Mon, 13 Jan 2014 14:20:59 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>
> >> On Mon, 13 Jan 2014 14:18:24 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>>
> >>> Today's linux-next merge of the tip tree got conflicts in
> >>> arch/arc/include/asm/Kbuild, arch/cris/include/asm/Kbuild,
> >>> arch/hexagon/include/asm/Kbuild,
> >>> arch/microblaze/include/asm/Kbuild,
> >>> arch/parisc/include/asm/Kbuild and
> >>> arch/score/include/asm/Kbuild between commit e3fec2f74f7f
> >>> ("lib: Add missing arch generic-y entries for
> >>> asm-generic/hash.h") from the net-next tree and commit
> >>> 93ea02bb8435 ("arch: Clean up asm/barrier.h implementations
> >>> using asm-generic/barrier.h") from the tip tree.
> >>>
> >>> I fixed it up (see below) and can carry the fix as necessary
> >>> (no action is required).
> >>>
> >>> BTW: thanks for not keeping the Kbuild files sorted :-(
> >>
> >> I missed arch/mn10300/include/asm/Kbuild the first time round.
> >
> > And ... git rerere does not work well here. It stores resolutions
> > by a hash of the (sanitised) conflict and since most of these files
> > have exactly the same conflict, I am going to have to edit 5 of
> > them by hand every day.
> >
>
> Well, you probably can keep a diff from the conflict-merge tree to the
> fix, but still.
>
> Is there a sensible way we can fix this in either net-next or tip?

Probably not now. If the respective patches had kept those Kbuild files
sorted, then (most of the) conflicts would not have happened.

Maybe if there were follow up patches that put them back in order it may
help. Or at least maybe make the conflicts different enough so that
git rerere would store them all.

I am just grumbling because I guessed this would happen when I saw the
patch go into the next-next tree (unfortunately, it was a report of mine
that caused that patch to be created :-().
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au




== 3 of 3 ==
Date: Mon, Jan 13 2014 9:20 pm
From: David Miller


From: "H. Peter Anvin" <hpa@zytor.com>
Date: Mon, 13 Jan 2014 20:51:43 -0800

> Is there a sensible way we can fix this in either net-next or tip?

I think if I sort the files in net-next the problem will go away,
if someone can confirm this I'll do it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: linux-next: manual merge of the akpm-current tree with the tip tree
http://groups.google.com/group/linux.kernel/t/dbed449ea85f37ac?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Jan 13 2014 9:00 pm
From: Stephen Rothwell


Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
kernel/futex.c between commit a52b89ebb6d4 ("futexes: Increase hash table
size for better performance") from the tip tree and commit 61beee6c76e5
("futex: switch to USER_DS for futex test") from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au

diff --cc kernel/futex.c
index 3666aa0017ed,66d23727c6ab..000000000000
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@@ -63,7 -63,7 +63,8 @@@
#include <linux/sched/rt.h>
#include <linux/hugetlb.h>
#include <linux/freezer.h>
+#include <linux/bootmem.h>
+ #include <linux/uaccess.h>

#include <asm/futex.h>

@@@ -2845,19 -2734,9 +2846,20 @@@ SYSCALL_DEFINE6(futex, u32 __user *, ua

static int __init futex_init(void)
{
+ mm_segment_t fs;
u32 curval;
- int i;
+ unsigned long i;
+
+#if CONFIG_BASE_SMALL
+ futex_hashsize = 16;
+#else
+ futex_hashsize = roundup_pow_of_two(256 * num_possible_cpus());
+