> "Waiman" == Waiman Long writes:
Waiman> On 09/04/2013 04:40 PM, John Stoffel wrote:
>>> "Waiman" == Waiman Long writes:
Waiman> In term of AIM7 performance, this patch has a performance boost of
Waiman> about 6-7% on top of Linus' lockref patch on a 8-socket 80-core DL980.
>>
Waiman>
On Tue, 3 Sep 2013 00:48:53 -0400
Luiz Capitulino wrote:
> The second patch fixes a softlockup which is fully described and now is
> 100% reproducible with simple steps. The first patch fixes a bug I found
> while working on the second patch.
Can someone look at this series please? This is a
On Thu, Sep 05, 2013 at 07:39:56AM +1000, Benjamin Herrenschmidt wrote:
> Hi Folks !
>
> It appears that the current version of irq_exit() calls __do_softirq()
> directly rather than do_softirq().
>
> That means we are going to call the softirq's in the current interrupt
> frame rather than on
於 四，2013-09-05 於 11:31 +0100，Matt Fleming 提到：
> On Thu, 05 Sep, at 06:13:36PM, joeyli wrote:
> > This S4WakeKey is a VOLATILE variable that could not modify by
> > SetVariable() at runtime. So, it's read only even through efivars.
> >
> > Does it what your concern?
>
> No, the UEFI spec
On Thu 05-09-13 07:54:30, Johannes Weiner wrote:
[...]
> From: Johannes Weiner
> Subject: [patch] mm: memcg: handle non-error OOM situations more gracefully
>
> Many places that can trigger a memcg OOM situation return gracefully
> and don't propagate VM_FAULT_OOM up the fault stack.
>
> It's
On 09/05/2013 08:21 PM, Paolo Bonzini wrote:
> Page tables in a read-only memory slot will currently cause a triple
> fault when running with shadow paging, because the page walker uses
> gfn_to_hva and it fails on such a slot.
>
> TianoCore uses such a page table. The idea is that, on real
On Thu, Sep 05, 2013 at 02:39:11PM +0200, Miklos Szeredi wrote:
> +static bool __has_unlinked_ancestor(struct dentry *dentry)
> +{
> + struct dentry *this;
> +
> + for (this = dentry; !IS_ROOT(this); this = this->d_parent) {
> + int is_unhashed;
> +
> + /* Need
On 4 September 2013 20:04, Jean Pihet wrote:
> From: Will Deacon
>
> This patch implements the functions required for the perf refs API,
'regs API' not 'refs API'
Regards,
Ard.
> allowing the perf tool to interface kernel register dumps with libunwind
> in order to provide userspace
On Thu, 05 Sep, at 11:34:52AM, Leif Lindholm wrote:
> This set breaks out some common code from x86/ia64 EFI support
> code and puts it into drivers/firmware/efi.
>
> First it takes the definition of the global "efi" data structure
> and moves it into global efi.c. Then it implements a common
On Thu, Sep 05, 2013 at 02:17:30PM +0100, Ard Biesheuvel wrote:
> On 5 September 2013 15:05, Jean Pihet wrote:
> [..]
> > Here are the commands I have been using:
> > perf record -g dwarf --
> > perf report --sort symbol --call-graph --stdio
> >
>
> Ah, I failed to add the 'dwarf' after -g,
On Thu, 2013-09-05 at 13:54 +0200, Rafael J. Wysocki wrote:
> On Wednesday, September 04, 2013 10:06:02 PM Alex Williamson wrote:
> > On Wed, 2013-09-04 at 21:37 -0600, Alex Williamson wrote:
> > > On Thu, 2013-09-05 at 01:35 +0200, Rafael J. Wysocki wrote:
> > > > On Wednesday, September 04, 2013
d472d9d9 "lockref: Relax in cmpxchg loop" added a cpu_relax() call to the
CMPXCHG_LOOP() macro. However to me it seems to be wrong since it is very
likely that the next round will succeed (or the loop will be left).
Even worse: cpu_relax() is very expensive on s390, since it means yield
"my
On 5 September 2013 15:05, Jean Pihet wrote:
[..]
> Here are the commands I have been using:
> perf record -g dwarf --
> perf report --sort symbol --call-graph --stdio
>
Ah, I failed to add the 'dwarf' after -g, however, in that case, my
perf report segfaults:
#0 locate_debug_info
* Ingo Molnar wrote:
> One thing I'm not seeing in the current Haswell code is the config set
> up for PERF_COUNT_HW_STALLED_CYCLES_FRONTEND/BACKEND. Both SB and IB has
> them configured.
Ping? Consider this a regression report.
Thanks,
Ingo
--
To unsubscribe from this list: send
2013/9/5 Rafael J. Wysocki :
> On Thursday, September 05, 2013 02:17:06 PM Lan Tianyu wrote:
>> 2013/9/5 Alex Williamson :
>> > On Thu, 2013-09-05 at 01:35 +0200, Rafael J. Wysocki wrote:
>> >> On Wednesday, September 04, 2013 05:12:14 PM Alex Williamson wrote:
>> >> > On Thu, 2013-09-05 at 00:54
On Thu, Sep 05, 2013 at 02:54:17PM +0200, Alexander Gordeev wrote:
> Do not trust the hardware and always check if MSI
> Revert to Single Message mode was enforced. Fall
> back to the single MSI mode in case it did. Not
> doing so might screw up the interrupt handling.
>
> Signed-off-by:
On 5 September 2013 14:45, Will Deacon wrote:
> Hi Jean,
>
> [adding Michael, since I know he was interested in this]
>
> On Wed, Sep 04, 2013 at 07:04:14PM +0100, Jean Pihet wrote:
>> On ARM the debug info is not present in the .eh_frame sections but
>> instead in .debug_frame.
>> Use libunwind
Hello,
On Thu, Sep 05, 2013 at 02:53:47PM +0200, Alexander Gordeev wrote:
> Make use of the new pci_enable_msi_block_part() interface
> and conserve on othewise wasted interrupt resources for 10
> of 16 unused MSI vectors on Intel chipsets.
>
> Signed-off-by: Alexander Gordeev
Acked-by: Tejun
Hello, Alexander.
On Thu, Sep 05, 2013 at 02:52:47PM +0200, Alexander Gordeev wrote:
> -int pci_enable_msi_block_part(struct pci_dev *dev,
> - unsigned int nvec, int nvec_mme)
> +int pci_get_msi_cap(struct pci_dev *dev)
> {
> - int status, maxvec;
> + int ret;
>
Hi Will,
On Thu, Sep 5, 2013 at 2:45 PM, Will Deacon wrote:
> Hi Jean,
>
> [adding Michael, since I know he was interested in this]
>
> On Wed, Sep 04, 2013 at 07:04:14PM +0100, Jean Pihet wrote:
>> On ARM the debug info is not present in the .eh_frame sections but
>> instead in .debug_frame.
Hi again Christoph,
On Wed, Sep 04, 2013 at 09:58:31PM +0100, Christoph Lameter wrote:
> Here is a patch to be applied after the earlier one to convert the local_t
> use to this_cpu. Not sure if I got the local_dec_and_test conversion
> right.
[...]
> @@ -118,11 +117,11 @@ void
>On Thu 05-09-13 14:33:43, azurIt wrote:
>[...]
>> >Just to be sure I got you right. You have killed all the processes from
>> >the group you have sent stacks for, right? If that is the case I am
>> >really curious about processes sitting in sleep_on_page_killable because
>> >those are killable by
On Thu, Sep 05, 2013 at 02:51:01PM +0200, Ingo Molnar wrote:
>
> * Frederic Weisbecker wrote:
>
> > > Btw., a side note, append_chain() is a rather confusing function in
> > > itself, with logic-inversion gems like:
> > >
> > > if (!found)
> > > found =
On Thu, 2013-09-05 at 11:16 +0100, Matt Fleming wrote:
> I'd advise checking efi_enabled(EFI_BOOT) along with .secure_boot to
> guard against garbage values in boot_params.
We've called sanitize_boot_params(), so we can assert that there are no
garbage values.
--
Matthew Garrett
There are no consumers of pci_enable_msi_block_auto()
interface have left. Eliminate it for now.
Signed-off-by: Alexander Gordeev
---
Documentation/PCI/MSI-HOWTO.txt | 42 +++---
drivers/pci/msi.c | 22
include/linux/pci.h
Do not trust the hardware and always check if MSI
Revert to Single Message mode was enforced. Fall
back to the single MSI mode in case it did. Not
doing so might screw up the interrupt handling.
Signed-off-by: Alexander Gordeev
---
drivers/ata/ahci.c | 16
drivers/ata/ahci.h
Changes since v1:
- use overcommit_ratio_ppm instead of overcommit_kbytes
- keep both variables in sync
Some applications that run on HPC clusters are designed around the
availability of RAM and the overcommit ratio is fine tuned to get the
maximum usage of memory without swapping. With
Make use of the new pci_enable_msi_block_part() interface
and conserve on othewise wasted interrupt resources for 10
of 16 unused MSI vectors on Intel chipsets.
Signed-off-by: Alexander Gordeev
---
drivers/ata/ahci.c | 46 +++---
1 files changed, 27
This change is a prerequisite for the forthcoming update
of the AHCI device driver to conserve 10/16 MSIs on Intel
chipsets. The update makes use of 'nvec_mme' parameter
for pci_enable_msi_block_part() interface.
Signed-off-by: Alexander Gordeev
---
drivers/iommu/irq_remapping.c | 12
* Frederic Weisbecker wrote:
> > Btw., a side note, append_chain() is a rather confusing function in
> > itself, with logic-inversion gems like:
> >
> > if (!found)
> > found = true;
>
> The check is pointless yeah, I'll remove that.
Are you sure it
Factor out the operation of retrieving the number of MSI
vectors the device requested, that is a value encoded in
the Multiple Message Capable register.
This change is a prerequisite for the forthcoming update
of the AHCI device driver.
Signed-off-by: Alexander Gordeev
---
There are PCI devices that require a particular value written
to the Multiple Message Enable (MME) register while aligned on
power of 2 boundary value of actually used MSI vectors 'nvec'
is a lesser of that MME value:
roundup_pow_of_two(nvec) < 'Multiple Message Enable'
However the
Hi Jean,
[adding Michael, since I know he was interested in this]
On Wed, Sep 04, 2013 at 07:04:14PM +0100, Jean Pihet wrote:
> On ARM the debug info is not present in the .eh_frame sections but
> instead in .debug_frame.
> Use libunwind to load and parse the debug info.
How have you tested
On Thu 05-09-13 14:33:43, azurIt wrote:
[...]
> >Just to be sure I got you right. You have killed all the processes from
> >the group you have sent stacks for, right? If that is the case I am
> >really curious about processes sitting in sleep_on_page_killable because
> >those are killable by
On Thu 05-09-13 07:54:30, Johannes Weiner wrote:
> On Wed, Sep 04, 2013 at 10:18:52AM +0200, azurIt wrote:
> > Ok, i see this message several times in my syslog logs, one of them
> > is also for this unremovable cgroup (but maybe all of them cannot
> > be removed, should i try?). Example of the
On Thu, Sep 05, 2013 at 12:56:39PM +0200, Ingo Molnar wrote:
>
> (Cc:-ed Frederic and Namhyung as well, it's about bad overhead in
> tools/perf/util/hist.c.)
>
> * Linus Torvalds wrote:
>
> > On Tue, Sep 3, 2013 at 6:29 AM, Ingo Molnar wrote:
> > >
> > > Please pull the latest
This one actually has a slight chance of working.
Thanks,
Miklos
---
Subject: vfs: check unlinked ancestors before mount
From: Miklos Szeredi
We check submounts before doing d_drop() on a non-empty directory dentry in
NFS (have_submounts()), but we do not exclude a racing mount. Nor do we
From: Thomas Bogendoerfer
The last line of PARISC machines (C8000, RP34x0, etc.) have a BMC for
controlling temperature, fan speed and other stuff. The BMC is connected
via a special bus and listed in the firmware device tree. This change
adds support for these BMCs to the IPMI driver.
>On Thu 05-09-13 13:47:02, azurIt wrote:
>> >On Thu 05-09-13 12:17:00, azurIt wrote:
>> >> >[...]
>> >> >> My script detected another freezed cgroup today, sending stacks. Is
>> >> >> there anything interesting?
>> >> >
>> >> >3 tasks are sleeping and waiting for somebody to take an action to
>>
I've pushed the non-Ceph bits of the bad-page fix to here:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=fscache
and added a CIFS fix.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Fix some typos in Documentation/IRQ-domain.txt/email-clients.txt/io-mapping.txt
Signed-off-by: Xishi Qiu
---
Documentation/IRQ-domain.txt|4 ++--
Documentation/email-clients.txt |2 +-
Documentation/io-mapping.txt|2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff
Hi!
On Tue 2013-08-27 18:13:57, Sebastian Capella wrote:
> Expand the existing documentation to explicitly list the options for
> resuming a hibernation image, including the manual resume option which
> can be used from the initrd or initramfs and the kernel init resume.
...it also fixes sysfs
A guest can still attempt to save and restore XSAVE states even if they
have been masked in CPUID leaf 0Dh. This usually is not visible to
the guest, but is still wrong: "Any attempt to set a reserved bit (as
determined by the contents of EAX and EDX after executing CPUID with
EAX=0DH, ECX= 0H)
Page tables in a read-only memory slot will currently cause a triple
fault when running with shadow paging, because the page walker uses
gfn_to_hva and it fails on such a slot.
TianoCore uses such a page table. The idea is that, on real hardware,
the firmware can already run in 64-bit flat mode
The current code has two exported functions, get_bytes_random() and
get_bytes_random_arch(). The first function only calls the entropy
store to get random data, and the second only calls the arch specific
hardware random number generator.
The problem is that no code is using the
ERROR: "flush_icache_user_range"
[drivers/staging/lustre/lustre/libcfs/libcfs.ko] undefined!
Signed-off-by: Geert Uytterhoeven
---
arch/m68k/mm/cache.c |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/m68k/mm/cache.c b/arch/m68k/mm/cache.c
index 3d84c1f..a19c888 100644
---
Rob Gittins writes:
> Direct Memory Mappable DIMMs (DMMD) appear in the system address space
> and are accessed via load and store instructions. These NVDIMMs
> are part of the system physical address space (SPA) as memory with
> the attribute that data survives a power interruption. As such
On Thursday, September 05, 2013 02:08:11 PM Pavel Machek wrote:
> Hi!
>
> Rafael, Al: apparently we have a regression caused by
> ba4df2808a86f8b103c4db0b8807649383e9bd13 .
I noticed that, but I'm not sure how to deal with it.
Also, s2disk still works on my test machines, so that seems to be
Hi!
Rafael, Al: apparently we have a regression caused by
ba4df2808a86f8b103c4db0b8807649383e9bd13 .
> > after a kernel update from 3.5.7 to the latest stable I found that
> > user-space resume (from suspend-1.0 aka uswsusp) no longer works.
> > Kernel-space suspend and resume work fine (e.g.
On Thu, Sep 5, 2013 at 2:02 PM, Miklos Szeredi wrote:
> On Thu, Sep 05, 2013 at 01:32:10PM +0200, Miklos Szeredi wrote:
>> On Thu, Sep 5, 2013 at 1:18 PM, Al Viro wrote:
>
>> > Something's really odd with locking here. You are take d_lock, do one
>> > check, set flag, drop d_lock, grab
On Thu 05-09-13 13:47:02, azurIt wrote:
> >On Thu 05-09-13 12:17:00, azurIt wrote:
> >> >[...]
> >> >> My script detected another freezed cgroup today, sending stacks. Is
> >> >> there anything interesting?
> >> >
> >> >3 tasks are sleeping and waiting for somebody to take an action to
> >>
OS Engineering writes:
> Hi Jeff,
>
> Thank you for reviewing the patch.
No problem. Jens, any objection to queueing this up for 3.12?
Cheers,
Jeff
>
> From: Jeff Moyer [jmo...@redhat.com]
> Sent: Friday, August 30, 2013 6:18 AM
> To: OS Engineering
>
On Thu, Sep 05, 2013 at 01:32:10PM +0200, Miklos Szeredi wrote:
> On Thu, Sep 5, 2013 at 1:18 PM, Al Viro wrote:
> > Something's really odd with locking here. You are take d_lock, do one
> > check, set flag, drop d_lock, grab rename_lock, do another check (taking
> > and dropping d_lock in
On Wed 2013-08-21 12:46:53, Sebastian Capella wrote:
> Expand the existing documentation to explicitly list the options for
> resuming a hibernation image, including the manual resume option which
> can be used from the initrd or initramfs and the kernel init resume.
>
> Signed-off-by: Sebastian
Hi azur,
On Wed, Sep 04, 2013 at 10:18:52AM +0200, azurIt wrote:
> > CC: "Andrew Morton" , "Michal Hocko"
> > , "David Rientjes" , "KAMEZAWA
> > Hiroyuki" , "KOSAKI Motohiro"
> > , linux...@kvack.org,
> > cgro...@vger.kernel.org, x...@kernel.org, linux-a...@vger.kernel.org,
> >
On Thursday, September 05, 2013 09:56:52 AM Tang Chen wrote:
> On 09/05/2013 07:50 AM, Rafael J. Wysocki wrote:
> > On Tuesday, September 03, 2013 04:45:37 PM Tang Chen wrote:
> >> This patch-set fix the following problems:
> >>
> >> 1. Kill useless function save_add_info() which will block us
On Thu, Sep 05, 2013 at 07:16:50PM +0800, wwang wrote:
> 于 2013年09月05日 18:48, Dan Carpenter 写道:
> >On Thu, Sep 05, 2013 at 05:45:38PM +0800, wei_w...@realsil.com.cn wrote:
> >>From: Wei WANG
> >>
> >>In some platforms, specially Thinkpad series, rts5249 won't be
> >>initialized properly. So we
>On Thu 05-09-13 12:17:00, azurIt wrote:
>> >[...]
>> >> My script detected another freezed cgroup today, sending stacks. Is
>> >> there anything interesting?
>> >
>> >3 tasks are sleeping and waiting for somebody to take an action to
>> >resolve memcg OOM. The memcg oom killer is enabled for that
Hi!
> It'd be better to send a removal of the whole lot.
>
> Does anyone still use this driver?
I do have the hardware, in subnotebook with terrible keyboard. So I do
not use it a lot.
Pavel
--
(english)
On Thursday, September 05, 2013 02:17:06 PM Lan Tianyu wrote:
> 2013/9/5 Alex Williamson :
> > On Thu, 2013-09-05 at 01:35 +0200, Rafael J. Wysocki wrote:
> >> On Wednesday, September 04, 2013 05:12:14 PM Alex Williamson wrote:
> >> > On Thu, 2013-09-05 at 00:54 +0200, Rafael J. Wysocki wrote:
>
On Wednesday, September 04, 2013 10:06:02 PM Alex Williamson wrote:
> On Wed, 2013-09-04 at 21:37 -0600, Alex Williamson wrote:
> > On Thu, 2013-09-05 at 01:35 +0200, Rafael J. Wysocki wrote:
> > > On Wednesday, September 04, 2013 05:12:14 PM Alex Williamson wrote:
> > > > On Thu, 2013-09-05 at
On Thu, 2013-09-05 at 12:30 +0100, Mark Rutland wrote:
> I also note that the device can also be attached to SPI. Do we have any
> other devices which may be attached to either? Do we handle that, and if
> so, how (do we have the same compatible string for both interfaces?)?
Theoretically you
From: "jordan_hargr...@dell.com"
I'd submitted this about a year ago but it never made it upstream.
The latest versions of the kernel drivers for ipmi can use ACPI to
determine the type of BMC device used in the system. The following
patch adds a module alias so that udev will autoload the
From: Corey Minyard
A couple of variables were getting warnings about being uninitialized.
It was a false warning, but initialize them, anyway.
Signed-off-by: Corey Minyard
---
drivers/char/ipmi/ipmi_msghandler.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Dan Carpenter
On x86_64 there is a 4 byte hole between ->recv_type and ->addr.
Signed-off-by: Dan Carpenter
Signed-off-by: Corey Minyard
---
drivers/char/ipmi/ipmi_devintf.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/char/ipmi/ipmi_devintf.c
Corey kicks himself for forgetting to sign off on some of these
and then resends with the signatures.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Sep 5, 2013 at 1:18 PM, Al Viro wrote:
> On Thu, Sep 05, 2013 at 11:44:37AM +0200, Miklos Szeredi wrote:
>> +static bool __has_unlinked_ancestor(struct dentry *dentry)
>> +{
>> + struct dentry *this;
>> +
>> + for (this = dentry; !IS_ROOT(this); this = this->d_parent) {
>> +
On Wed, Sep 04, 2013 at 04:11:59PM +0100, Lee Jones wrote:
> > Cheers for producing a binding.
> >
> > On Wed, Sep 04, 2013 at 02:50:55PM +0100, Lee Jones wrote:
> > > LPS001WP is a Pressure and Temperature sensor.
> > >
> > > Signed-off-by: Lee Jones
> > > ---
> > >
Jianguo Wu wrote:
> Changelog:
> *v1 -> v2: also update the stale comments about default transparent
> hugepage support pointed by Wanpeng Li.
>
> Since commit 13ece886d9(thp: transparent hugepage config choice),
> transparent hugepage support is disabled by default, and
>
On Thu, Sep 05, 2013 at 11:44:37AM +0200, Miklos Szeredi wrote:
> +static bool __has_unlinked_ancestor(struct dentry *dentry)
> +{
> + struct dentry *this;
> +
> + for (this = dentry; !IS_ROOT(this); this = this->d_parent) {
> + int is_unhashed;
> +
> + /* Need
On Thu 05-09-13 12:17:00, azurIt wrote:
> >[...]
> >> My script detected another freezed cgroup today, sending stacks. Is
> >> there anything interesting?
> >
> >3 tasks are sleeping and waiting for somebody to take an action to
> >resolve memcg OOM. The memcg oom killer is enabled for that group?
于 2013年09月05日 18:48, Dan Carpenter 写道:
On Thu, Sep 05, 2013 at 05:45:38PM +0800, wei_w...@realsil.com.cn wrote:
From: Wei WANG
In some platforms, specially Thinkpad series, rts5249 won't be
initialized properly. So we need adjust some phy parameters to
improve the compatibility issue.
* Alex Thorlton wrote:
> > Robin,
> >
> > I tweaked one of our other tests to behave pretty much exactly as I
> > - malloc a large array
> > - Spawn a specified number of threads
> > - Have each thread touch small, evenly spaced chunks of the array (e.g.
> > for 128 threads, the array is
* Alexey Vlasov wrote:
> On Sun, Aug 25, 2013 at 04:28:37PM +0200, Peter Zijlstra wrote:
>
> > and a function (or function-graph)
> > trace for when this happens?
>
> Unfortunately I could not make trace.
> First when migration threads start to eat CPUs and when I turn on trace:
> # echo
Linus,
Please pull the latest timers-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
timers-urgent-for-linus
HEAD: 5a8e01f8fa51f5cbce8f37acc050eb2319d12956 sched/cputime: Do not scale
when utime == 0
This fixes a longer-standing cputime
Linus,
Please pull the latest x86-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-urgent-for-linus
HEAD: 4488e09b4582c3d9cae1601351e26584e208d877 x86, doc: Add an entry in
MAINTAINERS for arch/x86/kernel/cpu/vmware.c
Fix for the annoying
When booting cpu, announce_cpu() is called to show which cpu is up
as following:
[0.402751] smpboot: Booting Node 0, Processors #1 #2 #3 #4 #5 OK
[0.525667] smpboot: Booting Node 1, Processors #6 #7 #8 #9 #10 #11 OK
[0.755592] smpboot: Booting Node 0, Processors #12 #13 #14
(Cc:-ed Frederic and Namhyung as well, it's about bad overhead in
tools/perf/util/hist.c.)
* Linus Torvalds wrote:
> On Tue, Sep 3, 2013 at 6:29 AM, Ingo Molnar wrote:
> >
> > Please pull the latest perf-core-for-linus git tree from:
>
> I don't think this is new at all, but I just tried to
AM43x has 224 interrupts and 7 banks, make it as maximum values. Keep
default values as earlier, if am43x is detected, update interrupts and
banks to maximum.
Also AM43x has only one cpu, ensure that clearing bitmask at wakeupgen
is done only for the single existing cpu, existing code assumes
On Thu, Sep 05, 2013 at 05:45:38PM +0800, wei_w...@realsil.com.cn wrote:
> From: Wei WANG
>
> In some platforms, specially Thinkpad series, rts5249 won't be
> initialized properly. So we need adjust some phy parameters to
> improve the compatibility issue.
>
> Signed-off-by: Wei WANG
> ---
>
Use "if (populated_zone(zone))" instead of "if (zone->present_pages)".
Simplify the code, no functional change.
Signed-off-by: Xishi Qiu
---
mm/page_alloc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index b100255..30ef67c
Common to (U)EFI support on all platforms is the global "efi" data
structure, and the code that parses the System Table to locate
addresses to populate that structure with.
This patch adds both of these to the global EFI driver code and
removes the local definition of the global "efi" data
early_ioremap() on IA64 chooses its mapping type based on the EFI
memory map. This patch adds an alias "early_memremap()" to be used
where the targeted location is memory rather than an i/o device.
Signed-off-by: Leif Lindholm
Acked-by: Tony Luck
---
arch/ia64/include/asm/io.h |1 +
1 file
I am announcing the release of the Linux 3.5.7.21 kernel.
The updated 3.5.y tree can be found at:
git://kernel.ubuntu.com/ubuntu/linux.git linux-3.5.y
and can be browsed at:
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;h=refs/heads/linux-3.5.y;a=shortlog
The diff from v3.5.7.20 is
efi_lookup_mapped_addr() is a handy utility for other platforms than
x86. Move it from arch/x86 to drivers/firmware. Add memmap pointer
to global efi structure, and initialise it on x86.
Signed-off-by: Leif Lindholm
---
arch/x86/platform/efi/efi.c | 30 ++
This set breaks out some common code from x86/ia64 EFI support
code and puts it into drivers/firmware/efi.
First it takes the definition of the global "efi" data structure
and moves it into global efi.c. Then it implements a common version
of efi_config_init().
Secondly it breaks the
kvm_vm_ioctl_get_dirty_log() write-protects the spte based on the its dirty
bitmap, so we should ensure the writable spte can be found in rmap before the
dirty bitmap is visible. Otherwise, we clear the dirty bitmap but fail to
write-protect the page which is detailed in the comments in this patch
Now we can flush all the TLBs out of the mmu lock without TLB corruption when
write-proect the sptes, it is because:
- we have marked large sptes readonly instead of dropping them that means we
just change the spte from writable to readonly so that we only need to care
the case of changing
Change the algorithm to:
1) always add new desc to the first desc (pointed by parent_ptes/rmap)
that is good to implement rcu-nulls-list-like lockless rmap
walking
2) always move the entry in the first desc to the the position we want
to remove when delete a spte in the parent_ptes/rmap
Currently, kvm zaps the large spte if write-protected is needed, the later
read can fault on that spte. Actually, we can make the large spte readonly
instead of making them un-present, the page fault caused by read access can
be avoided
The idea is from Avi:
| As I mentioned before,
It likes nulls list and we use the pte-list as the nulls which can help us to
detect whether the "desc" is moved to anther rmap then we can re-walk the rmap
if that happened
kvm->slots_lock is held when we do lockless walking that prevents rmap
is reused (free rmap need to hold that lock) so that
If the desc is the last one and it is full, its sptes is not counted
Signed-off-by: Xiao Guangrong
---
arch/x86/kvm/mmu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 6e2d2c8..7714fd8 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
Now, the only user of spte_write_protect is rmap_write_protect which
always calls spte_write_protect with pt_protect = true, so drop
it and the unused parameter @kvm
Signed-off-by: Xiao Guangrong
---
arch/x86/kvm/mmu.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
From: Duan Jiong
Casting (void *) value returned by kzalloc is useless
as mentioned in Documentation/CodingStyle, Chap 14.
Signed-off-by: Duan Jiong
---
drivers/staging/dgnc/dgnc_driver.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
The basic idea is from nulls list which uses a nulls to indicate
whether the desc is moved to different pte-list
Note, we should do bottom-up walk in the desc since we always move
the bottom entry to the deleted position. A desc only has 3 entries
in the current code so it is not a problem now,
Relax the tlb flush condition since we will write-protect the spte out of mmu
lock. Note lockless write-protection only marks the writable spte to readonly
and the spte can be writable only if both SPTE_HOST_WRITEABLE and
SPTE_MMU_WRITEABLE are set (that are tested by
Since pte_list_desc will be locklessly accessed we need to atomicly initialize
its pointers so that the lockless walker can not get the partial value from the
pointer
In this patch we use the way of assigning pointer to initialize its pointers
which is always atomic instead of using
It was removed by commit 834be0d83. Now we will need it to do lockless shadow
page walking protected by rcu, so reintroduce it
Signed-off-by: Xiao Guangrong
---
arch/x86/kvm/mmu.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/mmu.c
On Thu, 05 Sep, at 06:13:36PM, joeyli wrote:
> This S4WakeKey is a VOLATILE variable that could not modify by
> SetVariable() at runtime. So, it's read only even through efivars.
>
> Does it what your concern?
No, the UEFI spec probibits certain runtime functions from being
executed
Currently, when mark memslot dirty logged or get dirty page, we need to
write-protect large guest memory, it is the heavy work, especially, we
need to hold mmu-lock which is also required by vcpu to fix its page table
fault and mmu-notifier when host page is being changed. In the extreme
cpu /
401 - 500 of 1228 matches
Mail list logo
