On Fri, Dec 13, 2013 at 12:44:07PM +0530, Rashika Kheria wrote:
> This patch marks the functions do_write_buffer() and do_erase_oneblock()
> as static because because they are not used outside this file. It also
> removes the unused function word_program() in lpddr/lpddr_cmds.c.
>
> Thus, it also
On 17.12.2013 19:59, Eric Dumazet wrote:
On Tue, 2013-12-17 at 19:13 +0100, Knut Petersen wrote:
Hi Linus / everybody!
Booting openSuSE 13.1 with kernel 3.13.0-rc4 triggers the attached
warning.
cu,
Knut
Following patch should solve the issue.
http://patchwork.ozlabs.org/patch/301382/
On 12/12/2013 05:39 PM, Vladimir Davydov wrote:
> On 12/12/2013 05:21 PM, Michal Hocko wrote:
>> On Wed 11-12-13 10:22:06, Vladimir Davydov wrote:
>>> On 12/11/2013 03:13 AM, Glauber Costa wrote:
On Tue, Dec 10, 2013 at 5:59 PM, Vladimir Davydov
>> [...]
> -- memcg_update_cache_size(s,
On 2013-12-17 22:49, Sander Eikelenboom wrote:
Indeed, I looked for a crda hook for initramfs-tools but didn't find it, so
skipped that idea
for the moment.
So if i combine the two .. it's essentially just a very bad idea to compile the
wireless stuff in.
It needs a access to a userland
The function tty_vhangup_locked() was deprecated, removed it
from the tty.h also.
Signed-off-by: Liu, Chuansheng
---
include/linux/tty.h |1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 97d660e..a98c85f 100644
--- a/include/linux/tty.h
+++
Hi,
with the recent enablement of simplefb on x86, cirrusdrmfb on QEMU/KVM
gets broken now, as reported at:
https://bugzilla.novell.com/show_bug.cgi?id=855821
The cirrus VGA resource is reserved at first as "BOOTFB" in
arch/x86/kernel/sysfb_simplefb.c, which is taken by simplefb platform
Hi all,
Changes since 20131217:
Linus' tree lost its build failure.
The powerpc tree still had its build failure for which I applied a
supplied patch.
The pm tree gained a build failure so I used the version from
next-20131217.
The net-next tree gained a conflict against Linus' tree
On Mi, 2013-12-18 at 11:52 +1000, Dave Airlie wrote:
> On Wed, Dec 18, 2013 at 3:04 AM, Gerd Hoffmann wrote:
> > DRM driver for (virtual) vga cards using the bochs dispi
> > interface, such as the qemu standard vga (qemu -vga std).
> >
> > Don't bother supporting anything but 32bpp for now, even
there is an overflow in the following code :
ticks = fdata.timeout.sec * HZ;
while ticks is a signed 64-bit, but the result of fdata.timeout.sec *
HZ will be converted be 32-bit first. So ticks will be a wrong value
after multiplication overflow.
Reported-by: Qixue Xiao
Suggested-by: Yongjian
Hi Mel,
I'd like to share some test numbers with your patches applied on top of
v3.13-rc3.
Basically there are
1) no big performance changes
76628486 -0.7% 76107841 TOTAL vm-scalability.throughput
407038 +1.2% 412032 TOTAL hackbench.throughput
On Mon, Dec 16, 2013 at 03:43:43PM +0100, Ludovic Desroches wrote:
> Hello,
>
> On Fri, Dec 13, 2013 at 10:59:09AM +0900, Joonsoo Kim wrote:
> > On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> > > fix mmc mailing list address error
> > >
> > > On Thu, Dec 12, 2013 at
On 12/18/2013 12:47 AM, Vaughan Cao wrote:
> We do a normal login/logout process to iscsi server. iscsiadm report success,
> but we always see the following error just before conn shutdown in dmesg.
>
> Oct 15 05:30:09 vmhodtest019 iscsid: Connection1:0 to [target:
>
On Tue, Dec 17, 2013 at 02:59:06PM +0200, Ivan Khoronzhuk wrote:
> This series contains fixes and updates of Davinci nand driver in
> order to reuse it for Keystone platform.
>
> v3..v4:
> - mtd: nand: davinci: fix driver registration
> dropped __init/__exit/__exit_p as
There is a race condition if we map a same file on different processes.
Region tracking is protected by mmap_sem and hugetlb_instantiation_mutex.
When we do mmap, we don't grab a hugetlb_instantiation_mutex, but,
grab a mmap_sem. This doesn't prevent other process to modify region
structure, so it
Util now, we get a resv_map by two ways according to each mapping type.
This makes code dirty and unreadable. So unfiying it.
Reviewed-by: Aneesh Kumar K.V
Signed-off-by: Joonsoo Kim
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index ef70b6f..f394454 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@
Use helper functions to simplify _DSM related code in i2c-hid driver.
Signed-off-by: Jiang Liu
---
drivers/hid/i2c-hid/i2c-hid.c | 26 ++
1 file changed, 6 insertions(+), 20 deletions(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
index
Fix memory leak in function nouveau_optimus_dsm() and nouveau_dsm().
Signed-off-by: Jiang Liu
---
drivers/gpu/drm/nouveau/nouveau_acpi.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
b/drivers/gpu/drm/nouveau/nouveau_acpi.c
Use helper functions to simplify _DSM related code in nouveau driver.
After analyzing the ACPI _DSM related code, I changed nouveau_optimus_dsm()
to expect a buffer and nouveau_dsm() to expect an integer only.
Signed-off-by: Jiang Liu
---
drivers/gpu/drm/nouveau/core/subdev/mxm/base.c | 48
When searching ACPI object for TPM device, it should match current
ACPI object name instead of the full path.
Signed-off-by: Jiang Liu
---
drivers/char/tpm/tpm_ppi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/tpm/tpm_ppi.c b/drivers/char/tpm/tpm_ppi.c
Current pci-label driver detects ACPI label by checking label index
returned by ACPI _DSM method, and treat it as valid if label index
is positive. According to ACPI Firmware specification 3.1, zero is
also an valid label index. So change code to detect availability of
ACPI slot label by checking
Detecting physical presence interface features by checking availbility
of corresponding ACPI _DSM functions, it should be more accurate than
checking TPM version number.
Signed-off-by: Jiang Liu
---
drivers/char/tpm/tpm_ppi.c | 45 +++-
1 file changed,
Use helper functions to simplify _DSM related code in i915 driver.
Function intel_dsm() is used to check functions supported by ACPI _DSM
method, but it has strange check for special value 0x8002. After
digging into nouveau driver, I think the check is copied from nouveau
driver and is
Use helper functions to simplify _DSM related code in pci-label driver.
Also enforce more strict checks on objects returned by _DSM method.
Signed-off-by: Jiang Liu
---
drivers/pci/pci-label.c | 121 +--
1 file changed, 34 insertions(+), 87
In function ppi_callback(), memory allocated by acpi_get_name() will get
leaked when current device isn't the desired TPM device, so fix the
memory leak.
Signed-off-by: Jiang Liu
Cc: # 3.6
---
drivers/char/tpm/tpm_ppi.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
Use helper functions to simplify _DSM related code in TPM driver.
Signed-off-by: Jiang Liu
---
drivers/char/tpm/tpm_ppi.c | 404
1 file changed, 145 insertions(+), 259 deletions(-)
diff --git a/drivers/char/tpm/tpm_ppi.c
Use helper functions to simplify _DSM related code in acpi_extlog driver.
Also mark initialization data and functions with __init and __initdata
to reduce memory footprint.
Signed-off-by: Jiang Liu
---
drivers/acpi/acpi_extlog.c | 61 +---
1 file
On Wed, Dec 18, 2013 at 10:03:11AM +0800, micky_ch...@realsil.com.cn wrote:
> From: Micky Ching
>
> we add a macro to simplify setting pull control, and use a common init
> function to init the common params for 8411-like chips. at last we add
> support for rtl8402 chip.
>
> Micky Ching (2):
>
There are several drivers making use of ACPI _DSM method to detect
and invoke device specific methods. Currently every driver has
implemented its private version to support ACPI _DSM method.
So this patch introduces three helper functions to support ACPI _DSM
method, which will be used to replace
Function dsm_get_label() leaks the returned ACPI object if
obj->package.count is not 2, so fix the possible memory leak.
Signed-off-by: Jiang Liu
---
drivers/pci/pci-label.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/pci/pci-label.c
vma_has_reserves() can be substituted by using return value of
vma_needs_reservation(). If chg returned by vma_needs_reservation()
is 0, it means that vma has reserves. Otherwise, it means that vma don't
have reserves and need a hugepage outside of reserve pool. This definition
is perfectly same
* NOTE for v3
- Updating patchset is so late because of other works, not issue from
this patchset.
- While reviewing v2, David Gibson who had tried to remove this mutex long
time ago suggested that the race between concurrent call to
alloc_buddy_huge_page() in alloc_huge_page() is also
Currently, we have two variable to represent whether we can use reserved
page or not, chg and avoid_reserve, respectively. With aggregating these,
we can have more clean code. This makes no functinoal difference.
Reviewed-by: Aneesh Kumar K.V
Signed-off-by: Joonsoo Kim
diff --git
Current code include 'Caller expects lock to be held' in every error path.
We can clean-up it as we do error handling in one place.
Reviewed-by: Aneesh Kumar K.V
Signed-off-by: Joonsoo Kim
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 1817720..a9ae7d3 100644
--- a/mm/hugetlb.c
+++
In order to validate that this failure is reasonable, we need to know
whether allocation request is for reserved or not on caller function.
So moving vma_needs_reservation() up to the caller of alloc_huge_page().
There is no functional change in this patch and following patch use
this information.
If we fail with a allocated hugepage, we need some effort to recover
properly. So, it is better not to allocate a hugepage as much as possible.
So move up anon_vma_prepare() which can be failed in OOM situation.
Reviewed-by: Aneesh Kumar K.V
Signed-off-by: Joonsoo Kim
diff --git a/mm/hugetlb.c
If parallel fault occur, we can fail to allocate a hugepage,
because many threads dequeue a hugepage to handle a fault of same address.
This makes reserved pool shortage just for a little while and this cause
faulting thread who can get hugepages to get a SIGBUS signal.
To solve this problem, we
Now, we have an infrastructure in order to remove a this awkward mutex
which serialize all faulting tasks, so remove it.
Signed-off-by: Joonsoo Kim
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 843c554..6edf423 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2595,9 +2595,7 @@ static int
Currently, to track a reserved and allocated region, we use two different
ways for MAP_SHARED and MAP_PRIVATE. For MAP_SHARED, we use
address_mapping's private_list and, for MAP_PRIVATE, we use a resv_map.
Now, we are preparing to change a coarse grained lock which protect
a region structure to
Just move down outside_reserve check and don't check
vma_need_reservation() when outside_resever is true. It is slightly
optimized implementation.
This makes code more readable.
Reviewed-by: Aneesh Kumar K.V
Signed-off-by: Joonsoo Kim
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index
Now, alloc_huge_page() only return -ENOSPEC if failed.
So, we don't need to worry about other return value.
Reviewed-by: Aneesh Kumar K.V
Signed-off-by: Joonsoo Kim
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index d960f46..0f56bbf 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2621,7 +2621,6
In following patch, I change vma_resv_map() to return resv_map
for all case. This patch prepares it by removing resv_map_put() which
doesn't works properly with following change, because it works only for
HPAGE_RESV_OWNER's resv_map, not for all resv_maps.
Reviewed-by: Aneesh Kumar K.V
To change a protection method for region tracking to find grained one,
we pass the resv_map, instead of list_head, to region manipulation
functions. This doesn't introduce any functional change, and it is just
for preparing a next step.
Reviewed-by: Aneesh Kumar K.V
Signed-off-by: Joonsoo Kim
Move prototype declarations of function cper_estatus_print(),
cper_estatus_check_header() and cper_estatus_check() from file
drivers/acpi/apei/apei-internal.h to header file include/linux/cper.h
because these functions are used by both acpi driver and firmware
driver.
The header file
On Tue, Dec 17, 2013 at 10:17 PM, Rajat Jain wrote:
> Well, in that case I doubt if the patch will solve the problem. I think
> Most likely the "card present / not present" messages may be replaced
> By "link-up / link-down" messages. But I'd appreciate your testing.
I did have a debug patch at
We do a normal login/logout process to iscsi server. iscsiadm report success,
but we always see the following error just before conn shutdown in dmesg.
Oct 15 05:30:09 vmhodtest019 iscsid: Connection1:0 to [target:
iqn.1986-03.com.sun:02:7b863a18-045a-cb04-c686-841f17df2f9c, portal:
Hi Nicholas,
After merging the target-updates tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/target/target_core_alua.c: In function 'core_alua_state_lba_dependent':
drivers/target/target_core_alua.c:473:6: warning: suggest parentheses around
operand of '!'
Add the prototype declaration of function memory_block_size_bytes() in
memory.c.
This eliminates the following warning in memory.c:
drivers/base/memory.c:87:1: warning: no previous prototype for
‘memory_block_size_bytes’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
Reviewed-by: Josh
Mark function eoi_ioapic_pin_remapped() as static in irq_remapping.c
because it is not used outside this file.
This eliminates the following warning in
irq_remapping.c:drivers/iommu/irq_remapping.c:153:6: warning: no
previous prototype for ‘eoi_ioapic_pin_remapped’ [-Wmissing-prototypes]
Mark functions int get_irte() and ir_dev_scope_init() as static in
intel_irq_remapping.c because they are not used outside this file.
This eliminates the following warnings in intel_irq_remapping.c:
drivers/iommu/intel_irq_remapping.c:49:5: warning: no previous prototype for
‘get_irte’
Mark the functions check_zero_address() and dmar_get_fault_reason() as
static in dmar.c because they are not used outside this file.
This eliminates the following warnings in dmar.c:
drivers/iommu/dmar.c:491:12: warning: no previous prototype for
‘check_zero_address’ [-Wmissing-prototypes]
Hi,
I think this patch is useless.
It is possible to include dump code into Linux kernel for debugging purposes.
Thus we should do cleanup in different way for them.
Thanks
-Lv
> From: Rashika Kheria [mailto:rashika.khe...@gmail.com]
> Sent: Tuesday, December 17, 2013 5:24 PM
>
> Enclose
> On Tue, Dec 17, 2013 at 01:00:10PM +0100, Tomasz Figa wrote:
> > On Tuesday 17 of December 2013 11:51:36 Russell King - ARM Linux wrote:
> > > On Tue, Dec 17, 2013 at 12:10:22PM +0100, Thierry Reding wrote:
> > > > On Fri, Dec 13, 2013 at 04:57:04PM +0800, Xiubo Li wrote:
> > > > > +static
> -Original Message-
> From: yhlu.ker...@gmail.com [mailto:yhlu.ker...@gmail.com] On Behalf Of
>
> On Tue, Dec 17, 2013 at 7:20 PM, Rajat Jain
> wrote:
> >
> > Actually I did not understand the original problem and the solution in
> > the first place (so I also do not understand how
On Tue, Dec 17, 2013 at 03:02:10PM -0500, Johannes Weiner wrote:
> Hi Mel,
>
> On Tue, Dec 17, 2013 at 04:48:18PM +, Mel Gorman wrote:
> > This series is currently untested and is being posted to sync up discussions
> > on the treatment of page cache pages, particularly the sysv part. I have
Hi,
Currently we didn't do much on automatically optimized out ACPI_FUTURE_USAGE
functions as long as they do not affect the generation of vmlinux binary.
> From: Moore, Robert
> Sent: Wednesday, December 18, 2013 1:36 AM
>
> I'm not sure what version of ACPICA you are looking at, but in the
Hi Felipe,
Today's linux-next merge of the usb-gadget tree got a conflict in
drivers/usb/phy/Kconfig between commit 7cd0c298f6e0 ("usb: phy: fix
driver dependencies") from the usb.current tree and commit e1d2e31975e1
("usb: phy: Add OTG FSM configuration option") from the usb-gadget tree.
I
mach-mmp also uses ssp request/free APIs. Add mach-mmp support.
Otherwise there will be redefinition error.
Signed-off-by: Qiao Zhou
---
include/linux/pxa2xx_ssp.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/pxa2xx_ssp.h b/include/linux/pxa2xx_ssp.h
The local variable 'value' comes from 'extra', a parameter of function
'prism2_ioctl_priv_prism2_param'. If a large number passed to 'value',
there would be an integer overflow in the following line:
local->passive_scan_timer.expires = jiffies +
local->passive_scan_interval
Hi Greg,
Today's linux-next merge of the usb tree got a conflict in
drivers/usb/host/ohci-at91.c between commit fb5f1834c322 ("usb:
ohci-at91: fix irq and iomem resource retrieval") from the usb.current
tree and commit 3c9740a117d4 ("usb: hcd: move controller wakeup setting
initialization to
On Tue, 2013-12-17 at 10:27 -0800, Kees Cook wrote:
> This makes sure format strings cannot leak into the printk call via the
> constructed buffer.
[]
> diff --git a/drivers/scsi/esas2r/esas2r_log.c
> b/drivers/scsi/esas2r/esas2r_log.c
[]
> @@ -171,7 +171,7 @@ static int esas2r_log_master(const
In the attempt of get PREEMPT_RT working on sparc64 using
linux-stable-rt version 3.10.22-rt19+, the kernel crash
with the following trace:
[ 1487.027884] I7:
[ 1487.027885] Call Trace:
[ 1487.027887] [004967dc] rt_mutex_setprio+0x3c/0x2c0
[ 1487.027892] [004afe20]
This patch fixes the kernel crash faced while
trying to attempt linux-stable-rt v3.10.22-rt19
on sparc64.
[ 2317.606015] [008072f4] rt_spin_lock_slowlock+0x94/0x300
[ 2317.606020] [00451d74] get_new_mmu_context+0x14/0x160
[ 2317.606026] [00806394]
On Tue, 2013-12-17 at 18:59 -0800, Jean-Baptiste Theou wrote:
> This patch fixes wrong curly bracket position reporting when function
> declarations have only one void argument.
>
> Missing error (ERROR: space required before the open brace '{') on this
> situation :
>
> int foo(void){
>
On Tue, Dec 17, 2013 at 10:50:02PM +, Mark Brown wrote:
> On Thu, Dec 12, 2013 at 05:59:28PM +0800, Nicolin Chen wrote:
>
> > + mask = WM8962_MIXINL_TO_HPMIXL_MASK | WM8962_MIXINR_TO_HPMIXL_MASK |
> > + WM8962_IN4L_TO_HPMIXL_MASK | WM8962_IN4R_TO_HPMIXL_MASK;
> > + bypass |=
To help assuage the fears of those who think the NSA can introduce a
massive hack into the instruction decode and out of order execution
engine in the CPU without hundreds of Intel engineers knowing about
it (only one of which woud need to have the conscience and courage of
Edward Snowden to spill
Signed-off-by: Wenyou Yang
---
arch/arm/boot/dts/sama5d3xcm.dtsi | 46 +
1 file changed, 46 insertions(+)
diff --git a/arch/arm/boot/dts/sama5d3xcm.dtsi
b/arch/arm/boot/dts/sama5d3xcm.dtsi
index 726a0f3..4571751 100644
---
From: Namhyung Kim
The commit 09600e0f9ebb ("perf tools: Compare dso's also when
comparing symbols") added a comparison of dso when comparing symbol.
But if the sort key already has dso, it doesn't need to do it again
since entries have a different dso already filtered out.
Signed-off-by:
From: Namhyung Kim
The @entry argument already has the info so no need to pass them.
Signed-off-by: Namhyung Kim
---
tools/perf/util/hist.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index
Signed-off-by: Wenyou Yang
---
drivers/regulator/Kconfig |8 +
drivers/regulator/Makefile|1 +
drivers/regulator/act8865-regulator.c | 381 +
include/linux/regulator/act8865.h | 53 +
4 files changed, 443 insertions(+)
Hello,
This is my third attempt to implement cumulative hist period report.
This work begins from Arun's SORT_INCLUSIVE patch [1] but I completely
rewrote it from scratch.
Please see the patch 04/18. I refactored functions that add hist
entries with struct add_entry_iter. While I converted all
From: Namhyung Kim
If a hist entry doesn't have symbol information, compare it with its
address. Currently it only compares its level or whether it's NULL.
This can lead to an undesired result like an overhead exceeds 100%
especially when callchain accumulation is enabled by later patch.
Cc:
Commit 4d9b109060f690f5c835(tty: Prevent deadlock in n_gsm driver)
tried to close all the virtual ports synchronously before closing the
phycial ports, so the tty_vhangup() is used.
But the tty_unlock/lock() is wrong:
tty_release
tty_ldisc_release
tty_lock_pair(tty, o_tty) < == Here the tty
From: Namhyung Kim
hist_entry__add_cpumode_period() and hist_entry__decay() are dealing
with hist_entry's stat fields only. So make them use the struct
directly.
Cc: Arun Sharma
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/util/hist.c | 22 +++---
1
From: Namhyung Kim
It is possble that a callchain has cycles or recursive calls. In that
case it'll end up having entries more than 100% overhead in the
output. In order to prevent such entries, cache each callchain node
and skip if same entry already cumulated.
Cc: Arun Sharma
Cc: Frederic
From: Namhyung Kim
To support callchain accumulation, @entry should be recognized if it's
accumulated or not when add_hist_entry() called. The period of an
accumulated entry should be added to ->stat_acc but not ->stat. Add
@sample_self arg for that.
Cc: Arun Sharma
Cc: Frederic Weisbecker
From: Namhyung Kim
Maintain accumulated stat information in hist_entry->stat_acc if
symbol_conf.cumulate_callchain is set. Fields in ->stat_acc have same
vaules initially, and will be updated as callchain is processed later.
Cc: Arun Sharma
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
From: Namhyung Kim
There're some duplicate code when adding hist entries. They are
different in that some have branch info or mem info but generally do
same thing. So introduce new struct add_entry_iter and add callbacks
to customize each case in general way.
The new perf_evsel__add_entry()
From: Namhyung Kim
The cpumode and level in struct addr_localtion was set for a sample
and but updated as cumulative callchains were added. This led to have
non-matching symbol and cpumode in the output.
Update it accordingly based on the fact whether the map is a part of
the kernel or not.
From: Namhyung Kim
Call __hists__add_entry() for each callchain node to get an
accumulated stat for an entry. Introduce new cumulative_iter ops to
process them properly.
Cc: Arun Sharma
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-report.c | 136
From: Namhyung Kim
If -g cumulative option is given, it needs to show entries which don't
have self overhead. So apply percent-limit to accumulated overhead
percentage in this case.
Cc: Arun Sharma
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/ui/browsers/hists.c | 34
From: Namhyung Kim
Sometimes it needs to disable some columns at runtime. Add help
functions to support that.
Cc: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/ui/hist.c | 17 +
tools/perf/util/hist.h | 3 +++
2 files changed, 20 insertions(+)
diff --git
From: Namhyung Kim
The --cumulate option is for showing accumulated overhead (period)
value as well as self overhead.
Cc: Arun Sharma
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/Documentation/perf-report.txt | 5 +
tools/perf/builtin-report.c | 12
Hello,
Please don't break thread.
You should reply to my mail instead of your original post.
On Wed, Dec 18, 2013 at 01:29:37PM +0900, Chanho Min wrote:
>
> > I did test it on x86 with USB stick and ARM with eMMC on my Nexus 4.
> > In experiment, I couldn't see much gain like you both system
From: Namhyung Kim
Add report.cumulate config option for setting default value of
callchain accumulation. It affects the report output only if
perf.data contains callchain info.
A user can write .perfconfig file like below to enable accumulation
by default:
$ cat ~/.perfconfig
[report]
On Wed, Dec 18, 2013 at 12:58 PM, Tom Herbert wrote:
>>> Yes , in it's current state it's broken. But maybe we can try to fix
>>> it instead of arbitrarily removing it. Please see my patches on
>>> plumbing RFS into tuntap which may start to make it useful.
>> Do you mean you patch [5/5] tun:
From: Namhyung Kim
When callchain accumulation is requested, we need to sort the entries
by accumulated period value. When accumulated periods of two entries
are same (i.e. single path callchain) put the caller above since
accumulation tends to put callers on higher position for obvious
reason.
From: Namhyung Kim
Print accumulated stat of a hist entry if requested.
Cc: Arun Sharma
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/ui/browsers/hists.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/tools/perf/ui/browsers/hists.c
From: Namhyung Kim
Print accumulated stat of a hist entry if requested.
Cc: Arun Sharma
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/ui/hist.c | 45 +
tools/perf/util/hist.h | 1 +
2 files changed, 46 insertions(+)
diff
Signed-off-by: Wenyou Yang
---
.../bindings/regulator/act8865-regulator.txt | 58
.../devicetree/bindings/vendor-prefixes.txt|1 +
2 files changed, 59 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/act8865-regulator.txt
From: Namhyung Kim
Print accumulated stat of a hist entry if requested.
Cc: Arun Sharma
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/ui/gtk/hists.c | 16
1 file changed, 16 insertions(+)
diff --git a/tools/perf/ui/gtk/hists.c
Hi Mark,
Thanks a lot for your direction.
According to your advice, I prepared this version.
The patch set is to add act8865 PMIC driver.
The active-semi act8865 is designed as a PMIC for Atmel sama5d3x and at91sam9
series.
Its datasheet is available at:
On Tue, Dec 17, 2013 at 7:20 PM, Rajat Jain wrote:
>
> Actually I did not understand the original problem and the solution in the
> first
> place (so I also do not understand how might disabling of presence detect
> notification
> help). If you can give more details on the original problem that
>> Yes , in it's current state it's broken. But maybe we can try to fix
>> it instead of arbitrarily removing it. Please see my patches on
>> plumbing RFS into tuntap which may start to make it useful.
> Do you mean you patch [5/5] tun: Added support for RFS on tun flows?
> Sorry, can you say with
HI, Tom,
On Wed, Dec 18, 2013 at 12:06 PM, Tom Herbert wrote:
> On Mon, Dec 16, 2013 at 11:26 PM, Zhi Yong Wu wrote:
>> From: Zhi Yong Wu
>>
>> The flow cache is an extremely broken concept, and it usually brings up
>> growth issues and DoS attacks, so this patch is trying to remove it from
>>
On 17 December 2013 22:05, Kevin Hilman wrote:
> For future reference, for generating email friendly trace output for
> discussion like this, you can use something like:
>
>trace-cmd report --cpu=1 trace.dat
Okay..
>> And after that the next event comes after 5 Seconds.
>>
>> And so I was
> I did test it on x86 with USB stick and ARM with eMMC on my Nexus 4.
> In experiment, I couldn't see much gain like you both system and even it
> was regressed at bs=32k test, maybe workqueue allocation/schedule of work
> per I/O.
> Your test is rather special or what I am missing?
Can you
On Mon, Dec 09, 2013 at 18:10 Hedi Berriche wrote:
| Folks,
|
| The following panic occurs *early* at boot time on high *enough* CPU count
| machines:
|
| divide error: [#1] SMP
| Modules linked in:
| CPU: 22 PID: 1146 Comm: kworker/22:0 Not tainted 3.13.0-rc2-00122-gdea4f48 #8
| Hardware
The current implementation of IOMMU on sPAPR does not use iommu_ops
and therefore does not call IOMMU API's bus_set_iommu() which
1) sets iommu_ops for a bus
2) registers a bus notifier
Instead, PCI devices are added to IOMMU groups from
subsys_initcall_sync(tce_iommu_init) which does basically
Hi Arnaldo,
On Tue, 17 Dec 2013 17:02:39 -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Dec 17, 2013 at 09:02:36AM +0900, Namhyung Kim escreveu:
>> On Mon, 16 Dec 2013 09:40:51 -0300, Arnaldo Carvalho de Melo wrote:
>> > Em Mon, Dec 16, 2013 at 01:49:11PM +0900, Namhyung Kim escreveu:
>> >> On
On Mon, Dec 16, 2013 at 11:26 PM, Zhi Yong Wu wrote:
> From: Zhi Yong Wu
>
> The flow cache is an extremely broken concept, and it usually brings up
> growth issues and DoS attacks, so this patch is trying to remove it from
> the tuntap driver, and insteadly use a simpler way for its flow
1 - 100 of 1784 matches
Mail list logo
