[PATCH][v2] perf tools, powerpc: Fix compile warnings in tests/attr.c
We print several '__u64' quantities using '%llu'. On powerpc, we by
default include ' which results in __u64 being
an unsigned long. This causes compile warnings which are treated as
errors due to '-Werror'.
By defining __SANE
for tmp_part->header.name:
it is "Terminating null required only for names < 12 chars".
so need to limit the %.12s for it in printk
additional info:
%12s limit the width, not for the original string output length
if name length is more than 12, it still can be fully di
On Fri, Jan 11, 2013 at 11:11:17AM -0800, Sukadev Bhattiprolu wrote:
> If we disable a perf event because we exceeded the specified ->event_limit,
> power_pmu_stop() sets the PERF_HES_STOPPED flag on the event.
>
> If the application then re-enables the event using PERF_EVENT_IOC_ENABLE
> ioctl, w
On 01/24/2013 01:27 AM, Tejun Heo wrote:
> Hello, Srivatsa.
>
> On Thu, Jan 24, 2013 at 01:03:52AM +0530, Srivatsa S. Bhat wrote:
>> Hmm.. I split it up into steps to help explain the reasoning behind
>> the code sufficiently, rather than spring all of the intricacies at
>> one go (which would mak
On Tue, Jan 22, 2013 at 11:32 AM, Steven Rostedt wrote:
> On Tue, 2013-01-22 at 13:03 +0530, Srivatsa S. Bhat wrote:
>> A straight-forward (and obvious) algorithm to implement Per-CPU Reader-Writer
>> locks can also lead to too many deadlock possibilities which can make it very
>> hard/impossible
On Sun, 2013-01-06 at 18:49 +0800, Tiejun Chen wrote:
> In preempt case current arch_local_irq_restore() from
> preempt_schedule_irq() may enable hard interrupt but we really
> should disable interrupts when we return from the interrupt,
> and so that we don't get interrupted after loading SRR0/1.
On Thu, 2013-01-10 at 17:00 +0800, Li Zhong wrote:
> Use local_paca directly in arch_spin_unlock_wait(), as all processors have the
> same value for the field shared_proc, so we don't need care racy here.
Of course that won't build if CONFIG_PPC_SPLPAR isn't defined...
Maybe you could change the
On Wed, 2013-01-23 at 10:57 -0800, Sukadev Bhattiprolu wrote:
> Michael Ellerman [mich...@ellerman.id.au] wrote:
> | > | make: *** [tests/attr.o] Error 1
> | > |
> | > | i386 compiles fine
> | >
> | > __u64 is 'unsigned long long' on x86 and PRIu64 is 'llu' which is fine.
> | >
> | > __u64 is 'u
On Thu, 2013-01-24 at 09:36 +0800, Tang Chen wrote:
> On 01/24/2013 08:35 AM, Simon Jeons wrote:
> > On Wed, 2013-01-23 at 21:17 +0800, Tang Chen wrote:
> >> On 01/23/2013 08:29 PM, Simon Jeons wrote:
> >>> Hi Tang,
> >>>
> >>> I remember your big physical memory hot-remove patchset has already
> >
On 01/24/2013 08:35 AM, Simon Jeons wrote:
On Wed, 2013-01-23 at 21:17 +0800, Tang Chen wrote:
On 01/23/2013 08:29 PM, Simon Jeons wrote:
Hi Tang,
I remember your big physical memory hot-remove patchset has already
merged by Andrew, but where I can find it? Could you give me git tree
address?
Since all architectures have been converted to use vm_unmapped_area(),
there is no remaining use for the free_area_cache.
Signed-off-by: Michel Lespinasse
Acked-by: Rik van Riel
---
arch/arm/mm/mmap.c |2 --
arch/arm64/mm/mmap.c |2 --
arch/mips/mm/mmap.c
Update the powerpc slice_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
---
arch/powerpc/mm/slice.c | 123 ++-
1 files changed, 78 insertions(+), 45 deletion
As all other architectures have been converted to use vm_unmapped_area(),
we are about to retire the free_area_cache.
This change simply removes the use of that cache in
slice_get_unmapped_area(), which will most certainly have a
performance cost. Next one will convert that function to use the
vm_
Update the ia64 hugetlb_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
Acked-by: Rik van Riel
---
arch/ia64/mm/hugetlbpage.c | 20 +---
1 files changed, 9 insertions(+), 11 deletions(
Update the ia64 arch_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
Acked-by: Rik van Riel
---
arch/ia64/kernel/sys_ia64.c | 37 -
1 files changed, 12 insertions(+
Update the frv arch_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
Acked-by: Rik van Riel
---
arch/frv/mm/elf-fdpic.c | 49 --
1 files changed, 17 insertio
Update the alpha arch_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
Acked-by: Rik van Riel
---
arch/alpha/kernel/osf_sys.c | 20 +---
1 files changed, 9 insertions(+), 11 deletions(-
Update the parisc arch_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
Acked-by: Rik van Riel
---
arch/parisc/kernel/sys_parisc.c | 46 ++
1 files changed, 17 inser
This is a resend of my "finish the mission" patch series. I need arch
maintainers to approve so I can push this to andrew's -mm tree.
These patches, which apply on top of v3.8-rc kernels, are to complete the
VMA gap finding code I introduced (following Rik's initial proposal) in
v3.8-rc1.
First 5
On Wed, 2013-01-23 at 21:17 +0800, Tang Chen wrote:
> On 01/23/2013 08:29 PM, Simon Jeons wrote:
> > Hi Tang,
> >
> > I remember your big physical memory hot-remove patchset has already
> > merged by Andrew, but where I can find it? Could you give me git tree
> > address?
>
> Hi Simon,
>
> You ca
On 01/23/2013 11:27:29 AM, Gala Kumar-B11780 wrote:
On Jan 17, 2013, at 4:34 PM, Timur Tabi wrote:
> From: Timur Tabi
>
> The PAMU caches use the LIODNs to determine which cache lines hold
the
> entries for the corresponding LIODs. The LIODNs must therefore be
> carefully assigned to avoid
On 01/23/2013 11:41:26 AM, siva kumar wrote:
Hi ,
Is there any update on this , am getting in to the same state .
https://lists.ozlabs.org/pipermail/linuxppc-dev/2010-October/086680.html
Eran's initial comment of "This should probably go to the Freescale
support" seems right. You can reach
By moving the two JP12 jumpers 90 degrees, and switching the
setting of SW2.8, the sbc8548 can be configured to boot off
the alternate 64MB SODIMM, which when populated with u-boot
can be a handy recovery option, in case the u-boot in the
8MB soldered on flash gets corrupted. Here we add an altern
The original memory map for the sbc8548 had the 64MB SODIMM flash
device misaligned by 8MB to allow a window of address space for
the soldered on 8MB device -- i.e.
start end CS width Desc.
--
fb80_ ff7f
Updates to u-boot allow this board to boot off of either
the 8MB soldered on flash, or the 64MB SODIMM flash.
This is achieved by changing JP12 and SW2.8 which in turn
swaps which flash device appears on /CS0 and /CS6 respectively.
Since the flash devices are not the same size, this also
changes
The sbc8548 dts information for flash was out of date with respect
to u-boot configuration changes made just over a year ago. However
MTD support wasn't enabled by default, so the stale information
wasn't really an issue.
Here we update that information, split the dts file to allow
sharing the co
This board has soldered on flash, and a SODIMM flash module.
Both can be used for booting, via switching JP12 and SW2.8
and using the sbc8548-altflash.dts when booting from SODIMM.
Here we enable MTD in kernel so that we can see the bootloader
(and other flash sectors) from linux.
Normal configur
Hello, Srivatsa.
On Thu, Jan 24, 2013 at 01:03:52AM +0530, Srivatsa S. Bhat wrote:
> Hmm.. I split it up into steps to help explain the reasoning behind
> the code sufficiently, rather than spring all of the intricacies at
> one go (which would make it very hard to write the changelog/comments
> a
Hi ,
Is there any update on this , am getting in to the same state .
https://lists.ozlabs.org/pipermail/linuxppc-dev/2010-October/086680.html
Thanks,
Sivakumar
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo
On Tue, 2013-01-22 at 19:42 +0800, Tang Chen wrote:
> Here are some bug fix patches for physical memory hot-remove. All these
> patches are based on the latest -mm tree.
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
>
> And patch1 and patch3 are very important.
> patch1:
On 01/24/2013 12:25 AM, Tejun Heo wrote:
> Hello, Srivatsa.
>
> First of all, I'm not sure whether we need to be this step-by-step
> when introducing something new. It's not like we're transforming an
> existing implementation and it doesn't seem to help understanding the
> series that much eithe
Michael Ellerman [mich...@ellerman.id.au] wrote:
| > | make: *** [tests/attr.o] Error 1
| > |
| > | i386 compiles fine
| >
| > __u64 is 'unsigned long long' on x86 and PRIu64 is 'llu' which is fine.
| >
| > __u64 is 'unsigned long' on Power and PRIu64 is 'lu' which is again fine.
| >
| > But __
Hello, Srivatsa.
First of all, I'm not sure whether we need to be this step-by-step
when introducing something new. It's not like we're transforming an
existing implementation and it doesn't seem to help understanding the
series that much either.
On Tue, Jan 22, 2013 at 01:03:53PM +0530, Srivats
On 01/23/2013 11:23:51 AM, Kumar Gala wrote:
On Jan 21, 2013, at 7:56 PM, Scott Wood wrote:
> This will be used by the qemu-e500 platform, as the MPIC version
(and
> thus whether we have coreint) depends on how QEMU is configured.
>
> Signed-off-by: Scott Wood
> ---
> arch/powerpc/sysdev/mp
On Jan 17, 2013, at 4:34 PM, Timur Tabi wrote:
> From: Timur Tabi
>
> The PAMU caches use the LIODNs to determine which cache lines hold the
> entries for the corresponding LIODs. The LIODNs must therefore be
> carefully assigned to avoid cache thrashing -- two active LIODs with
> LIODNs that
On Jan 21, 2013, at 7:56 PM, Scott Wood wrote:
> This will be used by the qemu-e500 platform, as the MPIC version (and
> thus whether we have coreint) depends on how QEMU is configured.
>
> Signed-off-by: Scott Wood
> ---
> arch/powerpc/sysdev/mpic.c | 26 +++---
> 1 file c
On 01/23/2013 08:29 PM, Simon Jeons wrote:
Hi Tang,
I remember your big physical memory hot-remove patchset has already
merged by Andrew, but where I can find it? Could you give me git tree
address?
Hi Simon,
You can find all the physical memory hot-remove patches and related bugfix
patches f
Current irq_stat.timers_irqs counting doesn't discriminate timer event handler
and other timer interrupt(like arch_irq_work_raise). Sometimes we need to know
exactly how much interrupts timer event handler fired, so let's be more specific
on this.
Signed-off-by: Fan Du
---
arch/powerpc/include/a
38 matches
Mail list logo
