Commit-ID: 739390035c5fba2132fa424309786ff7bdd2cc1e
Gitweb: http://git.kernel.org/tip/739390035c5fba2132fa424309786ff7bdd2cc1e
Author: Suresh Siddha
AuthorDate: Fri, 24 Aug 2012 14:12:57 -0700
Committer: H. Peter Anvin
CommitDate: Fri, 24 Aug 2012 14:26:47 -0700
x86, fpu: drop_fpu() be
Some of our language runtimes like to map IP addresses in perf backtrace
to specific byte codes. The way things stand now, the addresses on the
backtrace are return addresses, rather than the caller. I think this
issue may be present for other unusual call/return sequences where the
user may be
Commit-ID: cc50fae05beb2db9f4587bbb1a0d6aba2af5b407
Gitweb: http://git.kernel.org/tip/cc50fae05beb2db9f4587bbb1a0d6aba2af5b407
Author: Suresh Siddha
AuthorDate: Fri, 24 Aug 2012 14:12:58 -0700
Committer: H. Peter Anvin
CommitDate: Fri, 24 Aug 2012 14:26:48 -0700
x86, fpu: remove unnece
Commit-ID: 98700fa647b3572f7fa55485570ab9fc53b91d23
Gitweb: http://git.kernel.org/tip/98700fa647b3572f7fa55485570ab9fc53b91d23
Author: Suresh Siddha
AuthorDate: Fri, 24 Aug 2012 14:12:59 -0700
Committer: H. Peter Anvin
CommitDate: Fri, 24 Aug 2012 14:26:49 -0700
x86, kvm: use kernel_fp
Commit-ID: 964735018df03c94dd12665385d59e3b2c7c08b8
Gitweb: http://git.kernel.org/tip/964735018df03c94dd12665385d59e3b2c7c08b8
Author: Suresh Siddha
AuthorDate: Fri, 24 Aug 2012 14:13:00 -0700
Committer: H. Peter Anvin
CommitDate: Fri, 24 Aug 2012 14:26:50 -0700
x86, fpu: always use ke
In drivers/usb/Kconfig "config USB_ARCH_HAS_HCD" is within "if USB_SUPPORT"
statement.
In drivers/gpu/drm/Kconfig "config DRM_USB" depends on USB_ARCH_HAS_HCD
but selects USB_SUPPORT which leads to the error for udl Kconfig:
$ yes "" | make oldconfig
scripts/kconfig/conf --oldconfig Kconfig
drive
Reported-By: Stephen Rothwell
Acked-by: Jani Nikula
Acked-by: Dave Airlie
Signed-off-by: Sedat Dilek
---
drivers/gpu/drm/i915/intel_modes.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_modes.c
b/drivers/gpu/drm/i915/intel_modes.c
index 29b7259..4bc1c0f 1006
This is a fixup patch for the merge of drm-next into linux-next caused
by commit b6c7488df68a ("drm/i915/contexts: fix list corruption").
Reported-By: Stephen Rothwell
Signed-off-by: Sedat Dilek
---
drivers/gpu/drm/i915/i915_gem.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
di
Commit-ID: 1ce83ffda9aea53e6e4b6b6a82c028a019526010
Gitweb: http://git.kernel.org/tip/1ce83ffda9aea53e6e4b6b6a82c028a019526010
Author: Suresh Siddha
AuthorDate: Fri, 24 Aug 2012 14:13:01 -0700
Committer: H. Peter Anvin
CommitDate: Fri, 24 Aug 2012 14:26:52 -0700
lguest, x86: handle gue
Commit-ID: 127f5403bfbc5f52cf0fbbadfa5e624a32a137ff
Gitweb: http://git.kernel.org/tip/127f5403bfbc5f52cf0fbbadfa5e624a32a137ff
Author: Suresh Siddha
AuthorDate: Fri, 24 Aug 2012 14:13:02 -0700
Committer: H. Peter Anvin
CommitDate: Fri, 24 Aug 2012 14:26:54 -0700
x86, fpu: use non-lazy
Hi,
On 24.08.2012 21:08, Josh Boyer wrote:
> We've had a report[1] that the Logitech USB headset 0003:046D:0A0C isn't
> working with 3.6-rc3. It seems the last working kernel was based on
> commit 10c63c9, and it first stopped working with a kernel based on
> commit 23dcfa6. There are only a few
On Fri, Aug 24, 2012 at 11:30:12PM +0200, Daniel Mack wrote:
> On Fri, Aug 24, 2012 at 9:08 PM, Josh Boyer wrote:
> > Hi All,
> >
> > We've had a report[1] that the Logitech USB headset 0003:046D:0A0C isn't
> > working with 3.6-rc3. It seems the last working kernel was based on
> > commit 10c63c9
On Fri, 24 Aug 2012 14:03:23 +0900
GShark Jeong wrote:
> I've reviewed and tested you patch ( lm3630 and lm3639) on my real board
> and these are working well .
> Thank you.
Great, thanks.
> ( Do I need to send back this patch to you again? or will the current
> status be applied for next bran
On Thu, 2012-08-23 at 15:26 +0200, Borislav Petkov wrote:
> On Fri, Aug 10, 2012 at 10:05:53AM +0800, Aaron Lu wrote:
> > commit a606dac368eed5696fb38e16b1394f1d049c09e9 adds support to link
> > devices which have _PRx, if a device does not have _PRx, a warning
> > message will be printed.
> >
> >
On Fri, Aug 24, 2012 at 11:31:44AM -0400, Justin Piszcz wrote:
> Hello,
>
> Thoughts?
>
> Saw this when trying to copy files to array with Samba and doing file
> operations:
>
> [28939.505792] [ cut here ]
> [29367.345433] BUG: unable to handle kernel NULL pointer derefer
Hello,
On Thu, Aug 23, 2012 at 04:53:27PM -0400, a...@redhat.com wrote:
> This series are a refreshed version of a patchset submitted by Li Zefan back
> in march:
> https://lkml.org/lkml/2012/3/1/13
Applied to cgroup/for-3.7 w/ "Original-Patch-by: Li Zefan" added for
the first three patches
>> Why do we need hash_head/hash_for_each_head()? I haven't stumbled on a place
>> yet
>> that needed direct access to the bucket itself.
>
> Because whole hash table walking is much less common and we can avoid
> another full set of iterators.
I don't agree. Out of 32 places which now use a has
On Sun, Aug 19, 2012 at 08:57:04PM -0700, Greg Kroah-Hartman wrote:
> From: Greg KH
>
> 3.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Daniel Vetter
>
> commit 0d8957c8a90bbb5d34fab9a304459448a5131e06 upstream.
>
> We may only sta
Hello,
On Sat, Aug 25, 2012 at 12:59:25AM +0200, Sasha Levin wrote:
> Thats the thing, the amount of things of things you can do with a given bucket
> is very limited. You can't add entries to any point besides the head (without
> walking the entire list).
Kinda my point. We already have all the
-Original Message-
From: Theodore Ts'o [mailto:ty...@mit.edu]
Sent: Friday, August 24, 2012 6:39 PM
To: Justin Piszcz
Cc: linux-kernel@vger.kernel.org; linux-e...@vger.kernel.org; al piszcz
Subject: Re: 3.5.1 kernel: Oops + stracktrace + ext4 kernel errors!
On Fri, Aug 24, 2012 at 11:31
Signed-off-by: Dave Jiang
---
drivers/dma/ioat/pci.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/dma/ioat/pci.c b/drivers/dma/ioat/pci.c
index 5e3a40f..c057306 100644
--- a/drivers/dma/ioat/pci.c
+++ b/drivers/dma/ioat/pci.c
@@ -40,6 +40
On Fri, Aug 24, 2012 at 11:22:05PM +0530, Laxman Dewangan wrote:
> I tried to reproduce the issue but could not able to do this.
> Can you please send me your board/dt files where you are porviding
> platform data for regulator?
> This will help me to reproduce the issue.
Here's a dts patch:
diff
Depending on the platform, init_memory_mapping() may be called multiple
times. Move it out to setup_arch() to avoid writing to cr4 on every call.
Signed-off-by: Jacob Shin
---
arch/x86/kernel/setup.c | 10 ++
arch/x86/mm/init.c | 10 --
2 files changed, 10 insertions(+),
Update code that previously assumed pfns [ 0 - max_low_pfn_mapped ) and
[ 4GB - max_pfn_mapped ) were always direct mapped, to now look up
pfn_mapped ranges instead.
Signed-off-by: Jacob Shin
---
arch/x86/kernel/cpu/amd.c |6 +-
arch/x86/platform/efi/efi.c |8
2 files chan
There could be cases where user supplied memmap=exactmap memory
mappings do not mark the region where the kernel .text .data and
.bss reside as E820_RAM as reported here:
https://lkml.org/lkml/2012/8/14/86
Handle it by complaining, and adding the range back into the e820.
Signed-off-by: Jacob Sh
Currently kernel direct mappings are created for all pfns between
[ 0 to max_low_pfn ) and [ 4GB to max_pfn ). When we introduce memory
holes, we end up mapping memory ranges that are not backed by physical
DRAM. This is fine for lower memory addresses which can be marked as UC
by fixed/variable ra
Current logic finds enough space for direct mapping page tables from 0
to end. Instead, we only need to find enough space to cover mr[0].start
to mr[nr_range].end -- the range that is actually being mapped by
init_memory_mapping()
This patch also reportedly fixes suspend/resume issue reported in:
Currently direct mappings are created for [ 0 to max_low_pfn<
---
arch/x86/include/asm/page_types.h |9 +++
arch/x86/kernel/setup.c | 125 +
arch/x86/mm/init.c|2 +
arch/x86/mm/init_64.c |6 +-
4 files changed,
[second send after HTML part made vger reject my first email]
On 32 Aug 2012, Ed Cashin writes:
> These patches go a long way to updating the in-kernel aoe driver with
> the changes that have been in the coraid.com-distributed version,
> bringing it from (aoe internal) version 47 to version 49.
nvpublic
> On Fri, Aug 24, 2012 at 04:23:39PM +0800, Bill Huang wrote:
> > When doing shutdown on Tegra20/Tegra30, we need to read/write PMIC
> > registers through I2C to perform the power off sequence.
> > Unfortunately, sometimes we'll fail to shutdown due to I2C timeout on
> > Tegra20. And the c
On Fri, Aug 24, 2012 at 06:55:14PM -0500, Jacob Shin wrote:
> Currently direct mappings are created for [ 0 to max_low_pfn< and [ 4GB to max_pfn< backed by actual DRAM. This is fine for holes under 4GB which are covered
> by fixed and variable range MTRRs to be UC. However, we run into trouble
> on
Quoting Chao Xie (2012-08-19 19:55:10)
> From: Chao Xie
> arch/arm/mach-mmp/Kconfig|3 +
> drivers/clk/Makefile |3 +
> drivers/clk/mmp/Makefile |9 +
> drivers/clk/mmp/clk-apbc.c | 152 ++
> drivers/clk/mmp/clk-apmu.c | 97 +
> drivers/clk/m
On 08/24/2012 04:55 PM, Jacob Shin wrote:
+
+ for (i = 0; i < e820.nr_map; i++) {
+ struct e820entry *ei = &e820.map[i];
+ u64 start = ei->addr;
+ u64 end = ei->addr + ei->size;
+
+ /* we only map E820_RAM */
+ if (ei->ty
Andrew Morton writes:
> On Fri, 17 Aug 2012 21:24:08 -0400
> Ed Cashin wrote:
...
>> +sigfillset(&blocked);
>> +sigprocmask(SIG_BLOCK, &blocked, NULL);
>> +flush_signals(current);
>
> This is a kernel thread - it shouldn't need to fiddle with signals.
...
Thanks for the feedback. I
nvpublic
> > On Sun, Aug 19, 2012 at 06:07:55PM -0700, Bill Huang wrote:
> > > Add DT property "ti,system-power-controller" telling whether or not
> > > this pmic is in charge of controlling the system power, so the power
> > > off routine can be hooked up to system call "pm_power_off".
> > >
> > >
On Fri, Aug 24, 2012 at 05:30:21PM -0700, H. Peter Anvin wrote:
> On 08/24/2012 04:55 PM, Jacob Shin wrote:
> >+
> >+for (i = 0; i < e820.nr_map; i++) {
> >+struct e820entry *ei = &e820.map[i];
> >+u64 start = ei->addr;
> >+u64 end = ei->addr + ei->size;
> >+
On 25/08/12 03:05, wbrana wrote:
> On 8/24/12, Martin Nybo Andersen wrote:
>> What I'd hate even more is rendering my old working hardware useless by
>> removing x86-32 support from the kernel. To reason the removal by saying
>> "Microsoft plans to do it" just makes me go bonkers...
> Your old har
DIV_ROUND_CLOSEST returns a bad result for negative dividends:
DIV_ROUND_CLOSEST(-2, 2) = 0
Most of the time this does not matter. However, in the hardware monitoring
subsystem, it is often used on integers which can be negative (such as
temperatures). Introduce new macro IDIV_ROUND_CLOSES
On 25/08/12 02:36, Alan Cox wrote:
>> almost all x86-32 boxes will be trash in 2017, remaining boxes will
>> use long term tree
> People will still be manufacturing 32bit x86 processors in 2017 I'm quite
> sure. You appear entirely out of touch. There are already serious
> discussions going on abou
On Fri, 2012-08-24 at 09:41 -0400, Steven Rostedt wrote:
> On Fri, 2012-08-24 at 15:15 +0800, Fengguang Wu wrote:
> > Hi Steven,
> >
> > The following test fails are mostly due to this commit, or one of the
> > last 4 commits in
> >
> > tree:
> > git://git.kernel.org/pub/scm/linux/kernel/git/
On Fri, Aug 24, 2012 at 4:55 PM, Jacob Shin wrote:
> Currently direct mappings are created for [ 0 to max_low_pfn< and [ 4GB to max_pfn< backed by actual DRAM. This is fine for holes under 4GB which are covered
> by fixed and variable range MTRRs to be UC. However, we run into trouble
> on higher
On 08/24/2012 05:49 PM, Jacob Shin wrote:
>
> Right, I think what I was attempting to do was to merge the 1MB
> with E820_RAM right above 1MB:
>
> So instead of:
>
> init_memory_mapping(0, 1MB)
> init_memory_mapping(1MB, 2GB)
>
> It would be:
>
> init_memory_mapping(0, 2GB)
>
> While taking c
On Fri, 2012-08-24 at 14:26 -0700, Paul E. McKenney wrote:
> On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
> > Hi,
> >
> > Changes since v1:
> >
> > - Fixed preempt handling in alpha idle loop
> > - added ack from Geert
> > - fixed stable email address, sorry :-/
> >
> > T
On Fri, Aug 24, 2012 at 4:55 PM, Jacob Shin wrote:
> There could be cases where user supplied memmap=exactmap memory
> mappings do not mark the region where the kernel .text .data and
> .bss reside as E820_RAM as reported here:
>
> https://lkml.org/lkml/2012/8/14/86
>
> Handle it by complaining, a
On Fri, Aug 24, 2012 at 4:55 PM, Jacob Shin wrote:
> Depending on the platform, init_memory_mapping() may be called multiple
> times. Move it out to setup_arch() to avoid writing to cr4 on every call.
>
> Signed-off-by: Jacob Shin
> ---
> arch/x86/kernel/setup.c | 10 ++
> arch/x86/mm/
From: Wei Yongjun
Using is_zero_ether_addr() instead of directly use
memcmp() to determine if the ethernet address is all
zeros.
spatch with a semantic match is used to found this problem.
(http://coccinelle.lip6.fr/)
Signed-off-by: Wei Yongjun
---
drivers/staging/csr/sme_wext.c | 4 +---
1 f
On Fri, Aug 24, 2012 at 6:25 PM, Yinghai Lu wrote:
> On Fri, Aug 24, 2012 at 4:55 PM, Jacob Shin wrote:
>> Depending on the platform, init_memory_mapping() may be called multiple
>> times. Move it out to setup_arch() to avoid writing to cr4 on every call.
>>
>> Signed-off-by: Jacob Shin
>> ---
>
On Fri, Aug 24, 2012 at 6:49 PM, Yinghai Lu wrote:
> On Fri, Aug 24, 2012 at 6:25 PM, Yinghai Lu wrote:
>> On Fri, Aug 24, 2012 at 4:55 PM, Jacob Shin wrote:
>>> Depending on the platform, init_memory_mapping() may be called multiple
>>> times. Move it out to setup_arch() to avoid writing to cr4
On 25/08/12 13:19, Ben Hutchings wrote:
> On Fri, 2012-08-24 at 14:26 -0700, Paul E. McKenney wrote:
>> On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
>>> Hi,
>>>
>>> Changes since v1:
>>>
>>> - Fixed preempt handling in alpha idle loop
>>> - added ack from Geert
>>> - fixed s
From: Wei Yongjun
Remove including that don't need it.
Signed-off-by: Wei Yongjun
---
kernel/kexec.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 0668d58..5e4bd78 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -21,7 +21,6 @@
#include
#inclu
Assume we have a 1GB(8Gb) nand chip, and we set the partitions
in the command line like this:
#gpmi-nand:100m(boot),100m(kernel),1g(rootfs)
In this case, the partition truncating occurs. The current code will
get the following result:
--
root@frees
Dear RT Folks,
I'm pleased to announce the 3.2.27-rt40 stable release.
This release is just an update to the new stable 3.2.27 version
and no RT specific changes have been made.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.g
On Fri, 2012-08-24 at 22:37 -0400, Steven Rostedt wrote:
> Dear RT Folks,
>
> I'm pleased to announce the 3.2.27-rt40 stable release.
Bah, Evolution is crashing on my /tmp directory (where my scripts place
the files). There's a bug in the gtk4 file manager (I'm using xfce),
where if the directory
Dear RT Folks,
I'm pleased to announce the 3.2.28-rt41 stable release.
This release is just an update to the new stable 3.2.28 version
and no RT specific changes have been made.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.g
Dear RT Folks,
This is the RT stable review cycle of patch 3.2.28-rt42-rc1.
Please scream at me if I messed something up. Please test the patches too.
The -rc release will be uploaded to kernel.org and will be deleted when
the final release is out. This is just a review release (or release cand
Updates console-make-rt-friendly.patch
#ifdef CONFIG_PREEMPT_RT_FULL, printk() output is never flushed by
printk() because:
# some liberties taken in this pseudo-code to make it easier to follow
printk()
vprintk()
raw_spin_lock(&logbuf_lock)
# increment preempt_co
---
localversion-rt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index 629e0b4..31c892a 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt41
+-rt42-rc1
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsub
On a dual port MCP55 10de:0373 (rev a3) NIC with both ports connected,
we identified a configuration that does freeze the whole NIC: having
autoneg & TX pause turned on while one port is physically connected
but interface is down (eg. eth1) eventually causes the whole NIC to
freeze (eth1 and... eth
Found by manual code inspection.
Tested: compile, reboot, ethtool -d ethX
Signed-off-by: David Decotigny
---
drivers/net/ethernet/nvidia/forcedeth.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/nvidia/forcedeth.c
b/drivers/net/ethernet/nvidia/for
On some dual-port forcedeth devices such as MCP55 10de:0373 (rev a3),
when autoneg & TX pause are enabled while port is connected but
interface is down, the NIC will eventually freeze (TX timeouts,
network unreachable).
This patch ensures that TX pause is not configured in hardware when
interface
This complements patch "net-forcedeth: fix TX timeout caused by TX
pause on down link" which ensures that a lock-up sequence is not sent
to the NIC. Present patch ensures that if a NIC is already locked-up,
the driver will recover from it when initializing the device.
It does the equivalent of the
On 08/23/2012 01:35 AM, Tony Prisk wrote:
> This patchset updates arch-vt8500 to devicetree and removes all the old-style
> code. Support for WM8650 has also been added.
>
> Example dts/dtsi files are given for the three currently supported models.
>
> Major changes:
>
> GPIO code has been conve
On 08/24/2012 06:36 PM, Bill Huang wrote:
>>> On Sun, Aug 19, 2012 at 06:07:55PM -0700, Bill Huang wrote:
Add DT property "ti,system-power-controller" telling whether or not
this pmic is in charge of controlling the system power, so the power
off routine can be hooked up to system ca
On Fri, Aug 24, 2012 at 12:06 PM, G.Shark Jeong wrote:
> From: "G.Shark Jeong"
>
> LM3554 and LM3556 have similar functions but very different register map.
> This driver is a general version for LM355x,lm3554 and lm3556,led chips of TI.
> lm3556 driver can be replaced by this driver.
>
> LM3554
Dear RT Folks,
This is the RT stable review cycle of patch 3.0.41-rt62-rc1.
Please scream at me if I messed something up. Please test the patches too.
The -rc release will be uploaded to kernel.org and will be deleted when
the final release is out. This is just a review release (or release cand
Updates console-make-rt-friendly.patch
#ifdef CONFIG_PREEMPT_RT_FULL, printk() output is never flushed by
printk() because:
# some liberties taken in this pseudo-code to make it easier to follow
printk()
vprintk()
raw_spin_lock(&logbuf_lock)
# increment preempt_co
On Sat, Aug 25, 2012 at 02:19:14AM +0100, Ben Hutchings wrote:
> On Fri, 2012-08-24 at 14:26 -0700, Paul E. McKenney wrote:
> > On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
> > > Hi,
> > >
> > > Changes since v1:
> > >
> > > - Fixed preempt handling in alpha idle loop
> >
---
localversion-rt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index 9b7de93..fef6b3c 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt61
+-rt62-rc1
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsub
On Fri, Aug 24, 2012 at 06:25:38PM -0700, Yinghai Lu wrote:
> On Fri, Aug 24, 2012 at 4:55 PM, Jacob Shin wrote:
> > Depending on the platform, init_memory_mapping() may be called multiple
> > times. Move it out to setup_arch() to avoid writing to cr4 on every call.
> >
> > Signed-off-by: Jacob Sh
On Fri, Aug 24, 2012 at 07:06:42PM -0700, Yinghai Lu wrote:
> On Fri, Aug 24, 2012 at 6:49 PM, Yinghai Lu wrote:
> > On Fri, Aug 24, 2012 at 6:25 PM, Yinghai Lu wrote:
> >> On Fri, Aug 24, 2012 at 4:55 PM, Jacob Shin wrote:
> >>> Depending on the platform, init_memory_mapping() may be called mul
On Fri, Aug 24, 2012 at 06:13:02PM -0700, H. Peter Anvin wrote:
> On 08/24/2012 05:49 PM, Jacob Shin wrote:
> >
> > Right, I think what I was attempting to do was to merge the 1MB
> > with E820_RAM right above 1MB:
> >
> > So instead of:
> >
> > init_memory_mapping(0, 1MB)
> > init_memory_mappin
On 08/24/2012 09:20 PM, Jacob Shin wrote:
What is the benefit?
So that in the case where we have E820_RAM right above 1MB, we don't
call init_memory_mapping twice, first on 0 ~ 1MB and then 1MB ~ something
we only call it once. 0 ~ something.
So what is the benefit?
-hpa
--
H. P
On Fri, Aug 24, 2012 at 06:07:01PM -0700, Yinghai Lu wrote:
> On Fri, Aug 24, 2012 at 4:55 PM, Jacob Shin wrote:
> > Currently direct mappings are created for [ 0 to max_low_pfn< > and [ 4GB to max_pfn< > backed by actual DRAM. This is fine for holes under 4GB which are covered
> > by fixed and va
* Tejun Heo (t...@kernel.org) wrote:
> Hello,
>
> On Sat, Aug 25, 2012 at 12:59:25AM +0200, Sasha Levin wrote:
> > Thats the thing, the amount of things of things you can do with a given
> > bucket
> > is very limited. You can't add entries to any point besides the head
> > (without
> > walking
On Fri, Aug 24, 2012 at 06:23:48PM -0700, Yinghai Lu wrote:
> On Fri, Aug 24, 2012 at 4:55 PM, Jacob Shin wrote:
> > There could be cases where user supplied memmap=exactmap memory
> > mappings do not mark the region where the kernel .text .data and
> > .bss reside as E820_RAM as reported here:
>
On Fri, Aug 24, 2012 at 9:24 PM, Jacob Shin wrote:
> On Fri, Aug 24, 2012 at 06:07:01PM -0700, Yinghai Lu wrote:
>> On Fri, Aug 24, 2012 at 4:55 PM, Jacob Shin wrote:
>> > Currently direct mappings are created for [ 0 to max_low_pfn<> > and [ 4GB to max_pfn<> > backed by actual DRAM. This is fine
Memory fragmentation introduced by ballooning might reduce significantly
the number of 2MB contiguous memory blocks that can be used within a guest,
thus imposing performance penalties associated with the reduced number of
transparent huge pages that could be used by the guest workload.
This patch
Memory fragmentation introduced by ballooning might reduce significantly
the number of 2MB contiguous memory blocks that can be used within a guest,
thus imposing performance penalties associated with the reduced number of
transparent huge pages that could be used by the guest workload.
This patch
Memory fragmentation introduced by ballooning might reduce significantly
the number of 2MB contiguous memory blocks that can be used within a guest,
thus imposing performance penalties associated with the reduced number of
transparent huge pages that could be used by the guest workload.
This patch
The PATCH "mm: introduce compaction and migration for virtio ballooned pages"
hacks around putback_lru_pages() in order to allow ballooned pages to be
re-inserted on balloon page list as if a ballooned page was like a LRU page.
As ballooned pages are not legitimate LRU pages, this patch introduces
This patch introduces a new set of vm event counters to keep track of
ballooned pages compaction activity.
Signed-off-by: Rafael Aquini
---
drivers/virtio/virtio_balloon.c | 1 +
include/linux/vm_event_item.h | 8 +++-
mm/balloon_compaction.c | 2 ++
mm/migrate.c
Memory fragmentation introduced by ballooning might reduce significantly
the number of 2MB contiguous memory blocks that can be used within a guest,
thus imposing performance penalties associated with the reduced number of
transparent huge pages that could be used by the guest workload.
Besides ma
This driver can be built as a module, add MODULE_ALIAS for it.
Signed-off-by: Axel Lin
---
drivers/regulator/max8907-regulator.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/regulator/max8907-regulator.c
b/drivers/regulator/max8907-regulator.c
index 3a5104f..19c765a 100644
---
401 - 483 of 483 matches
Mail list logo
