On Tue, 2013-09-10 at 08:31 -0700, Linus Torvalds wrote:
>
> Don't be silly. Nobody wants an extra chip. Especially not one that is
> programmable separately from the hardware.
But if I've got device attached to pin 15 of a GPIO controller
, surely that has to be programmed separately from the
On Mon, 2013-09-09 at 18:32 +0400, Konstantin Khlebnikov wrote:
> Luiz Capitulino wrote:
> > I'm getting the following soft lockup:
> >
> > CPU: 6 PID: 2278 Comm: killall5 Tainted: GF3.11.0-rc7+ #1
> > Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> > 0099
Hello,
As you probably know, in the current Linux kernel there is a staging
driver for the RTL8187SE device (based on my older RTL8180/RTL8185
Linux driver), while there also a regular (not staging) driver
supporting older RTL8185 and RTL8180 devices
(net/wireless/rtl818x/rtl8180) .
As far as I
On Tue, 2013-09-10 at 11:54 -0400, Adam Jackson wrote:
> Suspend isn't an error condition, and I'm sick of seeing this (and only
> this) on the console when I suspend with quiet boot enabled.
[]
> diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c
[]
> @@ -262,7 +262,7 @@ static
On Tue, Sep 10, 2013 at 05:26:31PM +0300, Mika Westerberg wrote:
> On Tue, Sep 10, 2013 at 01:27:54PM +0100, Mark Brown wrote:
> > > There is one difference though -- runtime PM is now blocked by default and
> > > it needs to be unblocked from the userspace per each device.
> > ...as you say.
>
On 08/30/2013 04:19 AM, Rajendra Nayak wrote:
> []..
>
>> +
>> +#define pr_fmt(fmt) "%s: " fmt, __func__
>> +
>> +#ifdef DEBUG
>> +#define prn(num) printk(#num "=%d\n", num)
>> +#define prx(num) printk(#num "=%x\n", num)
>> +#else
>> +#define prn(num) do { } while (0)
>> +#define prx(num) do { }
On Tue, Sep 10, 2013 at 5:28 PM, Peter Zijlstra wrote:
> On Tue, Sep 10, 2013 at 07:15:19AM -0700, Stephane Eranian wrote:
>> The threshold is where to generate the interrupt. It does not mean
>> where to stop PEBS recording.
>
> It does, since we don't set a reset value. So once a PEBS assist
>
On Tue, Sep 10, 2013 at 04:45:32PM +0100, Gustavo Padovan wrote:
> Hi Dan,
>
> 2013-09-03 Dan Aloni :
>
> > Tested with this patch and a Bluetooth mouse on 3.10.10, on ThinkPad W530.
> >
> > Bus 001 Device 004: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0
> > [ThinkPad]
> >
> > T:
Suspend isn't an error condition, and I'm sick of seeing this (and only
this) on the console when I suspend with quiet boot enabled.
Signed-off-by: Adam Jackson
---
drivers/misc/mei/pci-me.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/mei/pci-me.c
On Tue, Sep 10, 2013 at 8:43 AM, Stephen Warren wrote:
>
> x86 PCs likely have at least some of this exact same HW, e.g. I2C-based
> LM90 thermal sensors. However, I /think/ this all gets hidden from the
> OS by ACPI or other firmware mechanisms. Do you prefer firmware
> abstraction over DT?
If
On 10 September 2013 20:14, wrote:
> From: Lan Tianyu
>
> The cpufreq_set_policy() has been removed by commit 632786c. So remove
> related comment.
> ---
> drivers/cpufreq/cpufreq.c | 4
> 1 file changed, 4 deletions(-)
I have got another patch that takes care of this while fixing other
On Tue, 10 Sep 2013, Olof Johansson wrote:
> On Tue, Sep 10, 2013 at 5:49 AM, Lee Jones wrote:
> > Signed-off-by: Lee Jones
> > ---
> > arch/arm/configs/u8500_defconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm/configs/u8500_defconfig
> >
On Tue, Sep 10, 2013 at 07:15:19AM -0700, Stephane Eranian wrote:
> The threshold is where to generate the interrupt. It does not mean
> where to stop PEBS recording.
It does, since we don't set a reset value. So once a PEBS assist
happens, that counter stops until we reprogram it in the PMI.
>
Export Xen symbols to dom0 via /proc/xen/xensyms (similar to /proc/kallsyms).
Signed-off-by: Boris Ostrovsky
---
drivers/xen/Kconfig | 5 ++
drivers/xen/xenfs/Makefile | 1 +
drivers/xen/xenfs/super.c| 3 +
drivers/xen/xenfs/xenfs.h| 1 +
On Tue, Sep 10, 2013 at 8:05 AM, David Woodhouse wrote:
>
> In cost-sensitive products (and what *isn't* cost-sensitive these days),
> you really don't want to have to put an extra EEPROM on the board
> somewhere
Don't be silly. Nobody wants an extra chip. Especially not one that is
programmable
nfsd changes for 3.12 are available from
git://linux-nfs.org/~bfields/linux.git nfsd-next
This was a very quiet cycle! Just a few bugfixes and some cleanup.
--b.
Harshula Jayasuriya (2):
nfsd: nfs4_file_get_access: need
Avoid trapping to hypervisor on each MSR access during interrupt handling.
Instead, use cached MSR values provided in shared xenpmu_data by Xen. When
handling is completed, flush the registers to hypervisor who will load them
into HW.
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/pmu.c
PMU emulation code: MSR caching in PMU context and LVTPC APIC
handling. (Portions of this code are taken from Xen's VPMU
implementation)
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/enlighten.c | 27 +++-
arch/x86/xen/pmu.c | 289 -
On Tue, Sep 10, 2013 at 08:29:16AM -0700, Arjan van de Ven wrote:
> also.. yuck on using "dec" "dec" sucks, please use "sub foo ,1"
> instead (dec sucks because of its broken flags behavior; it creates
> basically a bubble in the pipeline)
Then someone needs to go change:
atomic{,64}_dec*()
This is the Linux side of Xen PMU support for PV guests, including dom0. Only
kernel changes are here, toolstack patch will be provided separately.
Here is description from the hypervisor patch submission that applies to this
series as well:
This version has following limitations:
* For accurate
Map shared data structure that will hold CPU registers, VPMU context,
VCPU/PCPI IDs of the VCPU interrupted by PMU interrupt. Hypervisor
fills this information in its handler and passes it to the guest for
further processing.
Set up PMU VIRQ.
Signed-off-by: Boris Ostrovsky
---
Set Xen's PMU mode via /sys/hypervisor/pmu/pmu_mode. Add XENPMU hypercall.
Signed-off-by: Boris Ostrovsky
---
arch/x86/include/asm/xen/hypercall.h | 6 ++
arch/x86/xen/xen-head.S | 5 +-
drivers/xen/sys-hypervisor.c | 118 +++
On 9/10/2013 6:56 AM, Ingo Molnar wrote:
* Ingo Molnar wrote:
So what we do in kick_process() is:
preempt_disable();
cpu = task_cpu(p);
if ((cpu != smp_processor_id()) && task_curr(p))
smp_send_reschedule(cpu);
preempt_enable();
The
> On Tue, Sep 10, 2013 at 5:49 AM, Lee Jones wrote:
> > Turns out that they're actually not required and the driver probes just
> > fine without them. The ID is incorrect at the moment anyway. They actually
> > currently specify the stn8815.
> >
> > Signed-off-by: Lee Jones
>
> How did you test
On 10 September 2013 20:42, Guennadi Liakhovetski wrote:
> 4. reverted that commit, resolving a trivial conflict. Added a debug
> output in __cpufreq_driver_target() of
>
>
> if (cpufreq_disabled())
> return -ENODEV;
> + pr_info("%s() %d\n", __func__,
On Tue, Sep 10, 2013 at 07:02:51AM -0700, Eric Dumazet wrote:
> On Tue, 2013-09-10 at 15:08 +0200, Peter Zijlstra wrote:
>
> > +static __always_inline int preempt_count(void)
> > +{
> > + return __this_cpu_read_4(__preempt_count) & ~PREEMPT_NEED_RESCHED;
> > +}
>
> Not sure why you used the _4
Hi,
On Tue, Sep 10, 2013 at 5:49 AM, Lee Jones wrote:
> Turns out that they're actually not required and the driver probes just
> fine without them. The ID is incorrect at the moment anyway. They actually
> currently specify the stn8815.
>
> Signed-off-by: Lee Jones
How did you test this
On Tue, Sep 10, 2013 at 05:09:57PM +0200, Markezana, William wrote:
> From: William Markezana
>
> hwmon: (ms5637) Add Measurement Specialties MS5637support
> Signed-off-by: William Markezana
Hi William,
"pressure" is hardly a hardware monitoring attribute. It might make more sense
to add your
On Tue, Sep 10, 2013 at 5:49 AM, Lee Jones wrote:
> Signed-off-by: Lee Jones
> ---
> arch/arm/configs/u8500_defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/configs/u8500_defconfig
> b/arch/arm/configs/u8500_defconfig
> index 6b29109..24f88d6 100644
> ---
On Tue, Sep 10, 2013 at 05:58:02PM +0300, Dan Carpenter wrote:
> Btw, the de...@driverdev.osuosl.org list seems to be down again. I
> still have not recieved the v3 patch. Use the
> driverdev-de...@linuxdriverproject.org email list instead.
They are the same "list", just different DNS entries.
From: Lan Tianyu
The cpufreq_set_policy() has been removed by commit 632786c. So remove
related comment.
---
drivers/cpufreq/cpufreq.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 5c75e31..a504313 100644
---
On Tue, 10 Sep 2013, Viresh Kumar wrote:
> On 9 September 2013 20:41, Guennadi Liakhovetski
> wrote:
> > Sorry guys, I'm trying my best to stop this patch from propagating to
> > stable and to get it fixed asap, so, the CC list might be a bit excessive.
> > Also trying to fix the originally
On Tue, Sep 10, 2013 at 03:56:36PM +0200, Ingo Molnar wrote:
> * Ingo Molnar wrote:
> > > * 8106f42a: 65 ff 0c 25 e0 b7 00decl %gs:0xb7e0
> > > 8106f431: 00
> > > * 8106f432: 0f 94 c0sete %al
> > > * 8106f435: 84
On Tue, Sep 10, 2013 at 01:31:41PM +0200, Stephan Mueller wrote:
> Hi,
>
> /dev/random uses the get_cycles() function to obtain entropy in addition to
> jiffies and the event value of hardware events.
>
> Typically the high-resolution timer of get_cycles delivers the majority of
> entropy,
On 09/10/2013 04:09 AM, Mark Brown wrote:
> On Mon, Sep 09, 2013 at 10:13:56PM -0600, Stephen Warren wrote:
>> On 09/09/2013 09:53 PM, Guenter Roeck wrote:
>
>>> Earlier comments suggest that this is not the intended use case
>>> for regulator_get_optional().
>
> That's right.
>
>> Isn't the
On Mon, 2013-09-09 at 16:49 -0700, Linus Torvalds wrote:
>
> Ok. I still really despise the absolute incredible sh*t that is
> non-discoverable buses, and I hope that ARM SoC hardware designers all
> die in some incredibly painful accident. DT only does so much.
Setting aside the inevitable
On 09/10/2013 05:18 AM, Laxman Dewangan wrote:
> The Turn-ON time of the regulator depends on the regulator device's
> electrical characteristics. Sometimes regulator turn-on time also
> depends on the capacitive load on the given platform and it can be
> more than the datasheet value.
>
> The
From: Lan Tianyu
The cpufreq_set_policy() has been removed by commit 632786c. So remove
related comment.
Signed-off-by: Lan Tianyu
---
Update: miss signed-off due to using my new script. Sorry for nosiy.
drivers/cpufreq/cpufreq.c | 4
1 file changed, 4 deletions(-)
diff --git
On 09/10/2013 08:17 AM, Javier Martinez Canillas wrote:
> On 09/10/2013 09:00 AM, Joel Fernandes wrote:
>> On 07/31/2013 03:35 AM, Javier Martinez Canillas wrote:
>>> On 07/31/2013 01:44 AM, Linus Walleij wrote:
On Tue, Jul 30, 2013 at 6:30 AM, Grant Likely
wrote:
> On Mon, Jul 29,
On 10 September 2013 17:19, Rafael J. Wysocki wrote:
> That said I'm actually unsure what problems *exactly* are fixed by commit
> 7c30ed5. The commit log only says that PRECHANGE or POSTCHAGE shouldn't be
> called twice in a row, but it doesn't say why. As the fallout indicates,
> that
On Fri, Aug 09, 2013 at 01:21:42AM -0400, Naoya Horiguchi wrote:
> Now we have extended hugepage migration and it's opened to many users
> of page migration, which is a good reason to consider hugepage as movable.
> So we can go to the direction to remove this parameter. In order to
> allow
Btw, the de...@driverdev.osuosl.org list seems to be down again. I
still have not recieved the v3 patch. Use the
driverdev-de...@linuxdriverproject.org email list instead.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On 09/08/2013 10:39 PM, Joonsoo Kim wrote:
On Sun, Sep 08, 2013 at 10:46:00AM -0400, Sasha Levin wrote:
Hi all,
While fuzzing with trinity inside a KVM tools guest, running latest -next
kernel, I've
stumbled on the following:
[ 998.281867] BUG: unable to handle kernel NULL pointer
Hi,
On Tue, 2013-09-10 at 08:59 -0500, Josh Cartwright wrote:
> [Hmm. Fixing b0rked LKML address; that might explain why I am not
> seeing Kumar's replies.]
>
Yes, sorry about this.
> On Tue, Sep 10, 2013 at 03:08:57PM +0300, Ivan T. Ivanov wrote:
> > Hi Kumar,
> >
> > On Fri, 2013-08-30
On Fri, Aug 09, 2013 at 01:21:38AM -0400, Naoya Horiguchi wrote:
> This patch extends do_mbind() to handle vma with VM_HUGETLB set.
> We will be able to migrate hugepage with mbind(2) after
> applying the enablement patch which comes later in this series.
>
> ChangeLog v3:
> - revert introducing
On (09/09/13 18:10), Jerome Marchand wrote:
> On 09/09/2013 03:46 PM, Jerome Marchand wrote:
> > On 09/09/2013 03:21 PM, Dan Carpenter wrote:
> >> On Mon, Sep 09, 2013 at 03:49:42PM +0300, Sergey Senozhatsky wrote:
> > Calling handle_pending_slot_free() for every RW operation may
> > cause
On Tue, Sep 10, 2013 at 7:29 AM, Ingo Molnar wrote:
>
> * Stephane Eranian wrote:
>
>> On Tue, Sep 10, 2013 at 6:38 AM, Ingo Molnar wrote:
>> >
>> > * Stephane Eranian wrote:
>> >
>> >> Hi,
>> >>
>> >> Ok, so I am able to reproduce the problem using a simpler
>> >> test case with a simple
On Fri, Aug 09, 2013 at 01:21:36AM -0400, Naoya Horiguchi wrote:
> This patch extends check_range() to handle vma with VM_HUGETLB set.
> We will be able to migrate hugepage with migrate_pages(2) after
> applying the enablement patch which comes later in this series.
>
> Note that for larger
On 09/10/2013 03:38 AM, farisdeh...@gmail.com wrote:
From: Faris de Haan
Fixed a few of the coding style issues reported by checkpatch.pl
Signed-off-by: Faris de Haan
---
drivers/staging/rtl8188eu/core/rtw_wlan_util.c | 22 +++---
1 file changed, 11 insertions(+), 11
* Stephane Eranian wrote:
> On Tue, Sep 10, 2013 at 6:38 AM, Ingo Molnar wrote:
> >
> > * Stephane Eranian wrote:
> >
> >> Hi,
> >>
> >> Ok, so I am able to reproduce the problem using a simpler
> >> test case with a simple multithreaded program where
> >> #threads >> #CPUs.
> >
> > Does it
This information can be found in /lib/modules/`uname -r`/modules.softdep, and
has only recently been exported by the kernel.
Also remove the advice about copying modules.softdep to /lib/modules as it is
not clear how to do this correctly with several kernels installed with
potentially conflicting
* Jan Beulich wrote:
> >>> On 10.09.13 at 15:42, Ingo Molnar wrote:
>
> > * Peter Zijlstra wrote:
> >
> >> + .macro SAVE_ALL
> >> + pushl_cfi %eax
> >> + CFI_REL_OFFSET eax, 0
> >> + pushl_cfi %ebp
> >> + CFI_REL_OFFSET ebp, 0
> >> + pushl_cfi %edi
> >> + CFI_REL_OFFSET edi, 0
> >> +
On Tue, 2013-09-10 at 17:21 +0300, Jani Nikula wrote:
> On Tue, 10 Sep 2013, Matthew Garrett wrote:
> > On Tue, 2013-09-10 at 16:53 +0300, Jani Nikula wrote:
> >
> >> I think the parameter "Does the ACPI backlight interface work or not"
> >> belongs to the ACPI video driver.
> >
> > That depends
On Tue, Sep 10, 2013 at 01:27:54PM +0100, Mark Brown wrote:
> On Tue, Sep 10, 2013 at 10:51:00AM +0300, Mika Westerberg wrote:
> > On Mon, Sep 09, 2013 at 04:40:28PM +0100, Mark Brown wrote:
>
> > > How is this going to interact with client devices which are already
> > > enabling runtime PM for
On Tue, 10 Sep 2013, Matthew Garrett wrote:
> On Tue, 2013-09-10 at 16:53 +0300, Jani Nikula wrote:
>
>> I think the parameter "Does the ACPI backlight interface work or not"
>> belongs to the ACPI video driver.
>
> That depends on how Windows 8 works. If Windows 8 policy is handled by
> the GPU
We kmalloc auxbuf but fail to kfree it if we get errors in various places.
Rework the error paths to avoid the resource leak.
Signed-off-by: Josh Boyer
---
fs/cachefiles/xattr.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/fs/cachefiles/xattr.c
On Tue, Sep 10, 2013 at 4:01 PM, Lucas De Marchi
wrote:
> On Wed, Jul 24, 2013 at 11:03 PM, Herbert Xu
> wrote:
>> On Thu, Jul 25, 2013 at 09:32:02AM +0930, Rusty Russell wrote:
>>> Herbert Xu writes:
>>> > Hi Rusty:
>>> >
>>> > I don't know why this patch never went into the kernel, even
>>> >
Hi Linus,
The following changes since commit b936bf8b785f0fbe083d203049e4da1c56ec788f:
dm cache: avoid conflicting remove_mapping() in mq policy (2013-08-16
15:56:51 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git
From: Namjae Jeon
v6: In v3 of the patch we released the allocated clutsers in
fat_file_release on the basis of d_count. Moving this from fat_file_release
to fat_evict_inode and on the basis of i_count , so that allocated
clusters are released at the last refrence of the inode when inode
evicts
On Tue, Sep 10, 2013 at 6:38 AM, Ingo Molnar wrote:
>
> * Stephane Eranian wrote:
>
>> Hi,
>>
>> Ok, so I am able to reproduce the problem using a simpler
>> test case with a simple multithreaded program where
>> #threads >> #CPUs.
>
> Does it go away if you use 'perf record --all-cpus'?
>
On Sat, Sep 07, 2013 at 10:44:00PM +0200, Toralf Förster wrote:
> Today I run latest git tree with a patched UML (this patch + one for xterm
> issues) and got 2 times a core dump
> when I fuzzy test an UML machine with a nearly identical scenario as already
> described but just shutdowned
> both
On Wed, Jul 24, 2013 at 11:03 PM, Herbert Xu
wrote:
> On Thu, Jul 25, 2013 at 09:32:02AM +0930, Rusty Russell wrote:
>> Herbert Xu writes:
>> > Hi Rusty:
>> >
>> > I don't know why this patch never went into the kernel, even
>> > though the corresponding features have been added to modprobe
>> >
On Tue, 2013-09-10 at 15:08 +0200, Peter Zijlstra wrote:
> +static __always_inline int preempt_count(void)
> +{
> + return __this_cpu_read_4(__preempt_count) & ~PREEMPT_NEED_RESCHED;
> +}
Not sure why you used the _4 prefix on all accessors ?
>
> +#ifdef CONFIG_PREEMPT_COUNT
> + /*
>
On 09/09, Eric W. Biederman wrote:
>
> Oleg Nesterov writes:
> >
> > Agreed, it also makes sense to clear ->nr_hashed. But I still think
> > that WARN_ON(ns->child_reaper) makes sense too.
>
> I don't know that I like warnings for impossible conditions.
But WARN_ON() should only check for
"case 0" in free_pid() assumes that disable_pid_allocation() should
clear PIDNS_HASH_ADDING before the last pid goes away. However this
doesn't happen if the 1st fork() fails to create the child reaper
which should call disable_pid_allocation().
Signed-off-by: Oleg Nesterov
---
kernel/pid.c |
[Hmm. Fixing b0rked LKML address; that might explain why I am not
seeing Kumar's replies.]
On Tue, Sep 10, 2013 at 03:08:57PM +0300, Ivan T. Ivanov wrote:
> Hi Kumar,
>
> On Fri, 2013-08-30 at 10:21 -0500, Kumar Gala wrote:
> > On Aug 29, 2013, at 12:26 PM, Ivan T. Ivanov wrote:
> > >>> +
> >
Dmitry Torokhov wrote:
> On Thu, Aug 15, 2013 at 04:55:57PM +0100, Nick Dyer wrote:
>> rydb...@euromail.se wrote:
>>> First: thanks for the patches and you work on this driver.
>>
>> Thank you for your time in looking at these changes.
>>
>>> Now, I don't swear much, but I would like to emphasize
On Tue, 2013-09-10 at 16:53 +0300, Jani Nikula wrote:
> I think the parameter "Does the ACPI backlight interface work or not"
> belongs to the ACPI video driver.
That depends on how Windows 8 works. If Windows 8 policy is handled by
the GPU drivers then it belongs in i915. If it's handled by the
>From 4675ca3470e3c2e325c5be6d9a11f47ac0917537 Mon Sep 17 00:00:00 2001
From: Eric Paris
Date: Tue, 10 Sep 2013 09:51:50 -0400
Subject: [PATCH] security: remove erroneous comment about capabilities.o link
ordering
Back when we had half ass LSM stacking we had to link capabilities.o
after bigger
On Tue, 2013-09-10 at 12:31 +0900, Yasuaki Ishimatsu wrote:
> (2013/09/10 9:24), Toshi Kani wrote:
:
> > diff --git a/kernel/cpu.c b/kernel/cpu.c
> > index d7f07a2..c10b285 100644
> > --- a/kernel/cpu.c
> > +++ b/kernel/cpu.c
> > @@ -420,11 +420,6 @@ int cpu_up(unsigned int cpu)
> > {
> >
On 09/10/2013 10:47 AM, Lars Poeschel wrote:
> On Tuesday 10 September 2013 17:19:24, Mark Brown wrote:
>> On Wed, Sep 04, 2013 at 02:16:36PM -0600, Stephen Warren wrote:
>> > On 09/04/2013 03:05 AM, Lars Poeschel wrote:
>> > > The driver that tries to use the GPIO requested by this patch before
* Ingo Molnar wrote:
> So what we do in kick_process() is:
>
> preempt_disable();
> cpu = task_cpu(p);
> if ((cpu != smp_processor_id()) && task_curr(p))
> smp_send_reschedule(cpu);
> preempt_enable();
>
> The preempt_disable() looks sweet:
>
>
>>> On 10.09.13 at 15:42, Ingo Molnar wrote:
> * Peter Zijlstra wrote:
>
>> +.macro SAVE_ALL
>> +pushl_cfi %eax
>> +CFI_REL_OFFSET eax, 0
>> +pushl_cfi %ebp
>> +CFI_REL_OFFSET ebp, 0
>> +pushl_cfi %edi
>> +CFI_REL_OFFSET edi, 0
>> +pushl_cfi %esi
>> +
* Peter Zijlstra wrote:
> These patches optimize preempt_enable by firstly folding the preempt and
> need_resched tests into one -- this should work for all architectures. And
> secondly by providing per-arch preempt_count implementations; with x86 using
> per-cpu preempt_count for fastest
On Mon, 09 Sep 2013, "Rafael J. Wysocki" wrote:
> On Monday, September 09, 2013 05:21:18 PM Daniel Vetter wrote:
>> On Mon, Sep 09, 2013 at 02:16:12PM +0200, Rafael J. Wysocki wrote:
>> > Hi,
>> >
>> > On Monday, September 09, 2013 11:32:10 AM Daniel Vetter wrote:
>> > > Hi Aaaron,
>> > >
>> >
On Fri, Aug 09, 2013 at 01:21:34AM -0400, Naoya Horiguchi wrote:
> Before enabling each user of page migration to support hugepage,
> this patch enables the list of pages for migration to link not only
> LRU pages, but also hugepages. As a result, putback_movable_pages()
> and migrate_pages() can
On Tue, Sep 10, 2013 at 02:35:27PM +0800, Libin wrote:
> From: Li Bin
>
> There is a redundant call for timer_stats_timer_set_start_info(),
> because it is the responsibility of the 'timer add' function:
>
> add_timer_on()
> |- timer_stats_timer_set_start_info()
>
> add_timer()
> |-
* Peter Zijlstra wrote:
> + .macro SAVE_ALL
> + pushl_cfi %eax
> + CFI_REL_OFFSET eax, 0
> + pushl_cfi %ebp
> + CFI_REL_OFFSET ebp, 0
> + pushl_cfi %edi
> + CFI_REL_OFFSET edi, 0
> + pushl_cfi %esi
> + CFI_REL_OFFSET esi, 0
> + pushl_cfi %edx
> +
On 09/10/2013 02:13 AM, Marek Szyprowski wrote:
It is not needed to include asm/dma-contiguous.h header to compile
reserved memory initialization code, so remove it to avoid build break
on architectures without CMA support.
Signed-off-by: Marek Szyprowski
Tested-by: Guenter Roeck
---
On Tue, 2013-09-10 at 09:50 +0800, Joe Jin wrote:
> On 09/09/13 21:41, Christoph Hellwig wrote:
> >> Modules linked in: oracleacfs(P)(U) oracleadvm(P)(U) oracleoks(P)(U)
> >
> > Please reproduce without this weird crap loaded.
> >
> These modules is filesystem and will not impact enclosure.
* Stephane Eranian wrote:
> Hi,
>
> Ok, so I am able to reproduce the problem using a simpler
> test case with a simple multithreaded program where
> #threads >> #CPUs.
Does it go away if you use 'perf record --all-cpus'?
> [ 2229.021934] WARNING: CPU: 6 PID: 17496 at
>
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git
tags/mmc-updates-for-3.12-rc1
to receive the MMC merge for 3.12. There are currently no conflicts,
and these patches have been tested in linux-next. Thanks.
The following changes since commit
Avoid unnecessary casts from int to bool in smp functions. Some
functions in kernel/smp.c have a wait parameter that can be set to one
if you want to wait for the command to complete. It's defined as bool
in a few of them and int in the rest. If a function with wait
declared as int calls a
On Tue, Sep 10, 2013 at 03:05:57PM +0930, Rusty Russell wrote:
> Frantisek Hrbata writes:
> > On Mon, Sep 09, 2013 at 10:44:03AM +0930, Rusty Russell wrote:
> >> Kyle McMartin writes:
> >> > On Fri, Sep 06, 2013 at 07:51:18PM +0200, Frantisek Hrbata wrote:
> >> >> > > v2: - reuse mod->ctors for
On Tue, Sep 10, 2013 at 03:08:17PM +0200, Peter Zijlstra wrote:
> @@ -1095,6 +1095,9 @@ DEFINE_PER_CPU(char *, irq_stack_ptr) =
>
> DEFINE_PER_CPU(unsigned int, irq_count) __visible = -1;
>
> +DEFINE_PER_CPU(int, __preempt_count) = INIT_PREEMPT_COUNT;
>
Remove the bloat of the C calling convention out of the
preempt_enable() sites by creating an ASM wrapper which allows us to
do an asm("call ___preempt_schedule") instead.
calling.h bits by Andi Kleen
Suggested-by: Linus Torvalds
Signed-off-by: Peter Zijlstra
---
Convert x86 to use a per-cpu preemption count. The reason for doing so
is that accessing per-cpu variables is a lot cheaper than accessing
thread_info variables.
We still need to save/restore the actual preemption count due to
PREEMPT_ACTIVE so we place the per-cpu __preempt_count variable in the
In order to combine the preemption and need_resched test we need to
fold the need_resched information into the preempt_count value.
We keep the existing TIF_NEED_RESCHED infrastructure in place but at 3
sites test it and fold its value into preempt_count; namely:
- resched_task() when setting
In order to prepare to per-arch implementations of preempt_count move
the required bits into an asm-generic header and use this for all
archs.
Signed-off-by: Peter Zijlstra
---
arch/alpha/include/asm/Kbuild |1
arch/arc/include/asm/Kbuild|1
arch/arm/include/asm/Kbuild
These patches optimize preempt_enable by firstly folding the preempt and
need_resched tests into one -- this should work for all architectures. And
secondly by providing per-arch preempt_count implementations; with x86 using
per-cpu preempt_count for fastest access.
These patches have been boot
* Stephane Eranian wrote:
> On Tue, Sep 10, 2013 at 5:51 AM, Ramkumar Ramachandra
> wrote:
> > Stephane Eranian wrote:
> >> a simple multithreaded program where
> >> #threads >> #CPUs
> >
> > To put it another way, does Intel's HT work for CPU intensive and IO
> > minimal tasks? I think HT
Replace the single preempt_count() 'function' that's an lvalue with
two proper functions:
preempt_count() - returns the preempt_count value as rvalue
preempt_count_ptr() - returns a pointer to the preempt_count
Then change all sites that modify the preempt count to use
preempt_count_ptr().
Su contraseña caducará en 3 días formulario llenar y enviar de inmediato para
validar su dirección de e-mail.
Nombre de Usuario: .
Contraseña anterior: .
Nueva Contraseña:
gracias
administrador del sistema
--
To unsubscribe from this list: send the
We need a few special preempt_count accessors:
- task_preempt_count() for when we're interested in the preemption
count of another (non-running) task.
- init_task_preempt_count() for properly initializing the preemption
count.
- init_idle_preempt_count() a special case of the above for
Rewrite the preempt_count macros in order to extract the 3 basic
preempt_count value modifiers:
__preempt_count_add()
__preempt_count_sub()
and the new:
__preempt_count_dec_and_test()
And since we're at it anyway, replace the unconventional
$op_preempt_count names with the more
On Wed, Sep 04, 2013 at 04:25:59PM -0700, David Rientjes wrote:
> We've been getting warnings about an excessive amount of time spent
> allocating pages for migration during memory compaction without
> scheduling. isolate_freepages_block() already periodically checks for
> contended locks or the
On 9 September 2013 07:15, Alexandre Courbot wrote:
> On Fri, Sep 6, 2013 at 3:35 AM, Rob Herring wrote:
>> On 09/04/2013 10:27 PM, Alexandre Courbot wrote:
>>> Trusted Foundations is a TrustZone-based secure monitor for ARM that
>>> can be invoked using a consistent SMC-based API on all
On 09/10/2013 09:00 AM, Joel Fernandes wrote:
> On 07/31/2013 03:35 AM, Javier Martinez Canillas wrote:
>> On 07/31/2013 01:44 AM, Linus Walleij wrote:
>>> On Tue, Jul 30, 2013 at 6:30 AM, Grant Likely
>>> wrote:
On Mon, Jul 29, 2013 at 6:36 AM, Linus Walleij
wrote:
> To solve
Em Tue, Sep 10, 2013 at 03:05:03PM +0200, Stephane Eranian escreveu:
> On Tue, Sep 10, 2013 at 3:00 PM, Arnaldo Carvalho de Melo
> wrote:
> > Em Mon, Sep 09, 2013 at 04:48:44PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Mon, Sep 09, 2013 at 04:47:45PM -0300, Arnaldo Carvalho de Melo
> >
> On Mon, Sep 9, 2013 at 7:28 AM, Wang Shilong
> wrote:
>> On 09/08/2013 12:15 AM, Azat Khuzhin wrote:
>>>
>>> Signed-off-by: Azat Khuzhin
>>> ---
>>> fs/btrfs/volumes.c |2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
601 - 700 of 1878 matches
Mail list logo
