During test patch
x86, mm: Use big page size for small memory range
found page table is setup wrongly for 32bit. And native_pagetable_init
wrongly cleared pte for pmd with large page support.
1. add more comments about why we are expecting pte.
2. add BUG checking, so next time we could
From: Jacob Shin
Currently direct mappings are created for [ 0 to max_low_pfn<
Signed-off-by: Yinghai Lu
Reviewed-by: Pekka Enberg
Reviewed-by: Konrad Rzeszutek Wilk
---
arch/x86/include/asm/page_types.h |8 +--
arch/x86/kernel/setup.c |8 ++-
arch/x86/mm/init.c
After we add code use buffer in BRK to pre-map buf for page table in
following patch:
x86, mm: setup page table in top-down
it should be safe to remove early_memmap for page table accessing.
Instead we get panic with that.
It turns out that we clear the initial page table wrongly for next
Will replace that with top-down page table initialization.
New API need to take range: init_range_memory_mapping()
Signed-off-by: Yinghai Lu
Reviewed-by: Konrad Rzeszutek Wilk
---
arch/x86/mm/init.c | 41 +++--
1 files changed, 19 insertions(+), 22 deletion
On 11/28/2012 01:47 PM, Yinghai Lu wrote:
> rebase patchset on top of linus v3.7-rc4. this one replace patches in
> tip/x86/mm2
What are the changes? Given how close we are to the merge window, if we
replace the entire patchset we are *definitely* slipping this to 3.9.
Depending on what the chan
instead of under 4g.
For 64bit, we can use any mapped mem instead of low mem.
Signed-off-by: Yinghai Lu
Reviewed-by: Konrad Rzeszutek Wilk
---
arch/x86/kernel/setup.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.
memblock_x86_fill() could double memory array.
If we set memblock.current_limit to 512M, so memory array could be around 512M.
So kdump will not get big range (like 512M) under 1024M.
Try to put it down under 1M, it would use about 4k or so, and that is limited.
Signed-off-by: Yinghai Lu
Reviewe
On Wednesday, November 28, 2012 02:40:09 PM Toshi Kani wrote:
> On Wed, 2012-11-28 at 22:40 +0100, Rafael J. Wysocki wrote:
> > On Wednesday, November 28, 2012 02:02:48 PM Toshi Kani wrote:
> > > > > > > > > > Consider the following case:
> > > > > > > > > >
> > > > > > > > > > We hotremove the me
Now all page table buf are pre-mapped, and we can use virtual address
directly. So don't need to remember physical address anymore.
Remove that phys pointer in alloc_low_page(), and that will allow us to
merge alloc_low_page between 64bit and 32bit.
Signed-off-by: Yinghai Lu
Acked-by: Stefano S
rebase patchset on top of linus v3.7-rc4. this one replace patches in
tip/x86/mm2
this one include patchset : x86, mm: init_memory_mapping cleanup
---
Current kernel init memory mapping between [0, TOML) and [4G, TOMH)
Some AMD systems have mem hole between 4G and TOMH, around 1T.
According to HP
could save some bit shifting operations.
Signed-off-by: Yinghai Lu
Reviewed-by: Konrad Rzeszutek Wilk
---
arch/x86/mm/init.c | 29 ++---
1 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 15fdaba..dd4e98d 1006
From: Jacob Shin
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.
Sig
It should take physical address range that will need to be mapped.
find_early_table_space should take range that pgt buff should be in.
Separate out page table size calculation to reduce confusing.
Signed-off-by: Yinghai Lu
Reviewed-by: Pekka Enberg
Reviewed-by: Konrad Rzeszutek Wilk
---
arch
So make init_memory_mapping smaller and readable.
-v2: use 0 instead of nr_range as input parameter found by Yasuaki Ishimatsu.
Suggested-by: Ingo Molnar
Signed-off-by: Yinghai Lu
Reviewed-by: Pekka Enberg
Reviewed-by: Konrad Rzeszutek Wilk
Cc: Yasuaki Ishimatsu
---
arch/x86/mm/init.c | 4
It will need to call split_mem_range() in following patch:
x86, mm: Change find_early_table_space() paramters
Move it down after that to avoid extra declaration.
Signed-off-by: Yinghai Lu
Reviewed-by: Konrad Rzeszutek Wilk
---
arch/x86/mm/init.c | 117 ++--
We could map small range in the middle of big range at first, so should use
big page size at first to avoid using small page size to break down page table.
Only can set big page bit when that range has ram area around it.
-v2: fix 32bit boundary checking. We can not count ram above max_low_pfn
We are going to map ram only in patch:
x86, mm: Only direct map addresses that are marked as E820_RAM
so range under max_low_pfn_mapped, ranges between 4g and max_pfn_mapped
could have holes in them and the holes will not be mapped.
Use pfn_range_is_mapped() to check if the range is mappe
We are going to map ram only in patch:
x86, mm: Only direct map addresses that are marked as E820_RAM
so range under max_low_pfn_mapped, ranges between 4g and max_pfn_mapped
could have holes in them and the holes will not be mapped.
Use pfn_range_is_mapped() to check if range is mapped fo
Current "memmap=" only can take one entry every time.
when we have more entries, we have to use memmap= for each of them.
For pxe booting, we have command line length limitation, those extra
"memmap=" would waste too much space.
This patch make memmap= could take several entries one time,
and tho
We should not do that in every calling of init_memory_mapping.
At the same time need to move down early_memtest, and could remove the
after_bootmem checking.
-v2: fix one early_memtest with 32bit by passing max_pfn_mapped instead.
Signed-off-by: Yinghai Lu
Reviewed-by: Konrad Rzeszutek Wilk
--
On Wed, 28 Nov 2012 22:45:34 +0100
Krzysztof Mazur wrote:
> On Wed, Nov 28, 2012 at 04:20:01PM -0500, chas williams - CONTRACTOR wrote:
> > i dont like the vcc->pop() implementation and at one point i had the
> > crazy idea of using skb->destructors to handle it. however, i think it
> > would be
Now NO_BOOTMEM version free_all_bootmem_node() does not really
do free_bootmem at all, and it only call register_page_bootmem_info_node
instead.
That is confusing, try to kill that free_all_bootmem_node().
Before that, this patch will remove numa_free_all_bootmem().
That function could be replac
Now we pass around use_gbpages and use_pse for calculating page table size,
Later we will need to call init_memory_mapping for every ram range one by one,
that mean those calculation will be done several times.
Those information are the same for all ram range and could be stored in
page_size_mask
Signed-off-by: Yinghai Lu
Reviewed-by: Konrad Rzeszutek Wilk
---
arch/x86/include/asm/numa.h|2 --
arch/x86/include/asm/numa_64.h |4
arch/x86/kernel/acpi/boot.c|1 -
arch/x86/kernel/cpu/amd.c |1 -
arch/x86/kernel/cpu/intel.c|1 -
arch/x86/kernel/setup.
save some lines, and make code more readable.
Signed-off-by: Yinghai Lu
Reviewed-by: Konrad Rzeszutek Wilk
---
arch/x86/mm/init.c | 21 +
1 files changed, 5 insertions(+), 16 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 1b8e80b..c8daa79 100644
-
call split_mem_range inside the function, that will make us call
split_mem_range two times. Following patch:
x86, mm: Find early page table buffer together
tidies this up so we do not end up calling split_mem_range twice.
Signed-off-by: Yinghai Lu
Reviewed-by: Konrad Rzeszutek Wilk
---
We try to put page table high to make room for kdump, and at that time
those ranges were not mapped yet, and had to use ioremap to access it.
Now after patch that pre-map page table top down.
x86, mm: setup page table in top-down
We do not need that workaround anymore.
Just use __va to re
We are going to use buffer in BRK to map small range just under memory top,
and use those new mapped ram to map ram range under it.
The ram range that will be mapped at first could be only page aligned,
but ranges around it are ram too, we could use bigger page to map it to
avoid small page size.
After
| commit 8548c84da2f47e71bbbe300f55edb768492575f7
| Author: Takashi Iwai
| Date: Sun Oct 23 23:19:12 2011 +0200
|
|x86: Fix S4 regression
|
|Commit 4b239f458 ("x86-64, mm: Put early page table high") causes a S4
|regression since 2.6.39, namely the machine reboots occasionally
On Wed, 28 Nov 2012, Al Viro wrote:
> On Wed, Nov 28, 2012 at 11:15:12AM -0800, Linus Torvalds wrote:
> > No, this is crap.
> >
> > We don't introduce random hooks like this just because the block layer
> > has shit-for-brains and cannot be bothered to do things right.
> >
> > The fact is, the
On Wed, 28 Nov 2012, Jeff Chua wrote:
> On Wed, Nov 28, 2012 at 12:01 PM, Mikulas Patocka wrote:
> > block_dev: don't take the write lock if block size doesn't change
> >
> > Taking the write lock has a big performance impact on the whole system
> > (because of synchronize_sched_expedited). Thi
Hi all,
I haven't been closely following things, but is there any reason that a
large number of these CONFIG_HOTPLUG and __dev* patches are being merged
via the driver-core tree rather than through the relevant maintainers
trees? They aren't particularly urgent as far as I can see. And they
alrea
On Wed, Nov 28, 2012 at 10:55:26PM +0800, Xiao Guangrong wrote:
> On 11/28/2012 10:01 PM, Gleb Natapov wrote:
> > On Wed, Nov 28, 2012 at 11:15:13AM +0800, Xiao Guangrong wrote:
> >> On 11/28/2012 07:32 AM, Marcelo Tosatti wrote:
> >>> On Tue, Nov 27, 2012 at 11:13:11AM +0800, Xiao Guangrong wrote:
On Wed, Nov 28, 2012 at 10:59:35PM +0800, Xiao Guangrong wrote:
> On 11/28/2012 10:12 PM, Gleb Natapov wrote:
> > On Tue, Nov 27, 2012 at 11:30:24AM +0800, Xiao Guangrong wrote:
> >> On 11/27/2012 06:41 AM, Marcelo Tosatti wrote:
> >>
>
> -return false;
> +again:
> +
On Wed, Nov 28, 2012 at 04:59:06PM -0500, chas williams - CONTRACTOR wrote:
> On Wed, 28 Nov 2012 22:45:34 +0100
> Krzysztof Mazur wrote:
>
> > On Wed, Nov 28, 2012 at 04:20:01PM -0500, chas williams - CONTRACTOR wrote:
> > > i dont like the vcc->pop() implementation and at one point i had the
>
On Wed, 28 Nov 2012, Linus Torvalds wrote:
> On Wed, Nov 28, 2012 at 12:32 PM, Linus Torvalds
> wrote:
> >
> > Here is a *COMPLETELY* untested patch. Caveat emptor. It will probably
> > do unspeakable things to your family and pets.
>
> Btw, *if* this approach works, I suspect we could just sw
[cc'ing linux-next]
On Wed, 2012-11-28 at 13:00 -0500, Peter Hurley wrote:
> Hi all,
>
> I couldn't find the v2 patch of this on linux-kernel but this commit
>
> 4660e32 "tasklet: ignore disabled tasklet in tasklet_action()"
>
> BUGS in -next-20121127.
>
> ---[cut here ]--
>
On Wed, 2012-11-28 at 23:01 +0100, Rafael J. Wysocki wrote:
> On Wednesday, November 28, 2012 02:40:09 PM Toshi Kani wrote:
> > On Wed, 2012-11-28 at 22:40 +0100, Rafael J. Wysocki wrote:
> > > On Wednesday, November 28, 2012 02:02:48 PM Toshi Kani wrote:
> > > > > > > > > > > Consider the followin
On Thu, Nov 29, 2012 at 09:04:12AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> I haven't been closely following things, but is there any reason that a
> large number of these CONFIG_HOTPLUG and __dev* patches are being merged
> via the driver-core tree rather than through the relevant maintainers
On Wednesday, November 28, 2012 03:04:52 PM Toshi Kani wrote:
> On Wed, 2012-11-28 at 23:01 +0100, Rafael J. Wysocki wrote:
> > On Wednesday, November 28, 2012 02:40:09 PM Toshi Kani wrote:
> > > On Wed, 2012-11-28 at 22:40 +0100, Rafael J. Wysocki wrote:
> > > > On Wednesday, November 28, 2012 02:
On Wed, 2012-11-28 at 09:21 +, David Laight wrote:
> Even when it might make sense to sleep in close until tx drains
> there needs to be a finite timeout before it become abortive.
You are, of course, right. We should never wait for hardware for ever.
And just to serve me right, I seem to have
> > > > > > I see. I do not think whether or not the device is removed on eject
> > > > > > makes any difference here. The issue is that after driver_unbind()
> > > > > > is
> > > > > > done, acpi_bus_hot_remove_device() no longer calls the ACPI memory
> > > > > > driver (hence, it cannot fail i
On Tue, Nov 20, 2012 at 1:08 AM, Huang Ying wrote:
> For unbound PCI devices, what we need is:
>
> - Always in D0 state, because some devices does not work again after
>being put into D3 by the PCI bus.
>
> - In SUSPENDED state if allowed, so that the parent devices can still
>be put int
Hello, guys.
cpuset implements its own descendant iteration using
cpuset->stack_list and has its own ->parent pointer. There's nothing
cpuset specific about descendant walking or finding the parent. This
patchset makes cpuset use cgroup generic API instead.
0001-cpuset-implement-cgroup_rightmo
Implement cpuset_for_each_descendant_pre() and replace the
cpuset-specific tree walking using cpuset->stack_list with it.
Signed-off-by: Tejun Heo
---
kernel/cpuset.c | 123 ++--
1 file changed, 48 insertions(+), 75 deletions(-)
diff --git a/k
cgroup already tracks the hierarchy. Follow cgroup->parent to find
the parent and drop cpuset->parent.
Signed-off-by: Tejun Heo
---
kernel/cpuset.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index 3a01730.
Implement cgroup_rightmost_descendant() which returns the right most
descendant of the specified cgroup. This can be used to skip the
cgroup's subtree while iterating with
cgroup_for_each_descendant_pre().
Signed-off-by: Tejun Heo
Cc: Michal Hocko
---
include/linux/cgroup.h | 1 +
kernel/cgro
Cesar Eduardo Barros wrote:
> I think I will wait for your patch. Since you probably created it with the
> same scripts used for the original move to uapi/, it should have less chance
> of mistakes than my ad-hoc shell scripting.
I haven't scripted it.
David
--
To unsubscribe from this list: se
On Wed, Nov 28, 2012 at 11:10:40PM +0100, Krzysztof Mazur wrote:
> On Wed, Nov 28, 2012 at 04:59:06PM -0500, chas williams - CONTRACTOR wrote:
> > On Wed, 28 Nov 2012 22:45:34 +0100
> > Krzysztof Mazur wrote:
> >
> > > On Wed, Nov 28, 2012 at 04:20:01PM -0500, chas williams - CONTRACTOR
> > > wr
On Wednesday, November 28, 2012 03:16:22 PM Toshi Kani wrote:
> > > > > > > I see. I do not think whether or not the device is removed on
> > > > > > > eject
> > > > > > > makes any difference here. The issue is that after
> > > > > > > driver_unbind() is
> > > > > > > done, acpi_bus_hot_remove
On Wednesday, November 28, 2012 03:25:59 PM Bjorn Helgaas wrote:
> On Tue, Nov 20, 2012 at 1:08 AM, Huang Ying wrote:
> > For unbound PCI devices, what we need is:
> >
> > - Always in D0 state, because some devices does not work again after
> >being put into D3 by the PCI bus.
> >
> > - In S
Em 28-11-2012 20:30, David Howells escreveu:
Cesar Eduardo Barros wrote:
I think I will wait for your patch. Since you probably created it with the
same scripts used for the original move to uapi/, it should have less chance
of mistakes than my ad-hoc shell scripting.
I haven't scripted it.
On 11/29/2012 05:57 AM, Marcelo Tosatti wrote:
> On Wed, Nov 28, 2012 at 10:59:35PM +0800, Xiao Guangrong wrote:
>> On 11/28/2012 10:12 PM, Gleb Natapov wrote:
>>> On Tue, Nov 27, 2012 at 11:30:24AM +0800, Xiao Guangrong wrote:
On 11/27/2012 06:41 AM, Marcelo Tosatti wrote:
>>
>>
> > > > > > I think it has some challenge as well. We bind an ACPI driver with
> > > > > > device_register(), which calls device_add()-> kobject_add(). So,
> > > > > > all
> > > > > > non-present ACPI device objects will show up in sysfs, unless we can
> > > > > > change the core. This will cha
On Wed, Nov 28, 2012 at 12:17:30PM -0800, K. Y. Srinivasan wrote:
>
> Greg,
You are writing the most unhelpful Subject: lines lately, please be more
descriptive in the future.
> I recently discovered that the Hyper-V host allocates mmio
> memory for some synthetic devices like the virtual frame
On Wednesday, November 28, 2012 03:33:27 PM Toshi Kani wrote:
> > > > > > > I think it has some challenge as well. We bind an ACPI driver
> > > > > > > with
> > > > > > > device_register(), which calls device_add()-> kobject_add(). So,
> > > > > > > all
> > > > > > > non-present ACPI device obj
On Wed, Nov 28, 2012 at 11:39:22PM +0100, Rafael J. Wysocki wrote:
> On Wednesday, November 28, 2012 03:16:22 PM Toshi Kani wrote:
> > > > > > > > I see. I do not think whether or not the device is removed on
> > > > > > > > eject
> > > > > > > > makes any difference here. The issue is that afte
On Wed, 28 Nov 2012 10:13:59 +
Mel Gorman wrote:
> Based on the reports I've seen I expect the following to work for 3.7
>
> Keep
> 96710098 mm: revert "mm: vmscan: scale number of pages reclaimed by
> reclaim/compaction based on failures"
> ef6c5be6 fix incorrect NR_FREE_PAGES accounti
On Wed, Nov 28, 2012 at 1:29 PM, Mikulas Patocka wrote:
>
> The problem with this approach is that it is very easy to miss points
> where it is assumed that the block size doesn't change - and if you miss a
> point, it results in a hidden bug that has a little possibility of being
> found.
Umm. M
On Wed, 2012-11-28 at 23:49 +0100, Rafael J. Wysocki wrote:
> On Wednesday, November 28, 2012 03:33:27 PM Toshi Kani wrote:
> > > > > > > > I think it has some challenge as well. We bind an ACPI driver
> > > > > > > > with
> > > > > > > > device_register(), which calls device_add()-> kobject_add(
The userspace audit tools didn't like the existing formatting of the
AUDIT_ANOM_LINK event. It needed to be expanded to emit an AUDIT_PATH
event as well, so this implements the change. The bulk of the patch is
moving code out of auditsc.c into audit.c and audit.h for general use.
It expands audit_l
On Wednesday, November 28, 2012 02:46:33 PM Greg KH wrote:
> On Wed, Nov 28, 2012 at 11:39:22PM +0100, Rafael J. Wysocki wrote:
> > On Wednesday, November 28, 2012 03:16:22 PM Toshi Kani wrote:
> > > > > > > > > I see. I do not think whether or not the device is removed
> > > > > > > > > on eject
On Wed, Nov 21, 2012 at 1:39 AM, Daniel J Blueman
wrote:
> Add NumaChip-specific PCI access mechanism via MMCONFIG cycles, but
> preventing access to AMD Northbridges which shouldn't respond.
>
> v2: Use PCI_DEVFN in precomputed constant limit; drop unneeded includes
>
> Signed-off-by: Daniel J Bl
Pavel Machek, le Mon 06 Feb 2012 15:19:23 +0100, a écrit :
> On Mon 2011-11-14 05:06:13, Samuel Thibault wrote:
> > Dmitry Torokhov, le Wed 12 Jan 2011 10:27:02 -0800, a écrit :
> > > > --- a/drivers/char/Kconfig
> > > > +++ b/drivers/char/Kconfig
> > > > @@ -8,6 +8,7 @@ config VT
> > > > b
On Thu, Nov 29, 2012 at 12:05:20AM +0100, Rafael J. Wysocki wrote:
> On Wednesday, November 28, 2012 02:46:33 PM Greg KH wrote:
> > > So, it looks like the driver core wants us to handle driver unbinding no
> > > matter what.
> >
> > Yes. Well, the driver core does the unbinding no matter what, i
Yes, the Nx586 was supported as a 386. Again, doubt anyone cares at this point.
Alan Cox wrote:
>On Wed, 28 Nov 2012 11:50:28 -0800
>"H. Peter Anvin" wrote:
>
>> From: "H. Peter Anvin"
>>
>> All 486+ CPUs support WP in supervisor mode, so remove the fallback
>> 386 support code.
>
>This brea
On Wed, Nov 28, 2012 at 2:52 PM, Linus Torvalds
wrote:
>
>> For example, __block_write_full_page and __block_write_begin do
>> if (!page_has_buffers(page)) { create_empty_buffers... }
>> and then they do
>> WARN_ON(bh->b_size != blocksize)
>> err = get_block(inode, block, b
On Wed, 28 Nov 2012 02:29:08 -0800
Anton Vorontsov wrote:
> The main characteristics are the same to what I've tried to add to vmevent
> API:
>
> Internally, it uses Mel Gorman's idea of scanned/reclaimed ratio for
> pressure index calculation. But we don't expose the index to the
> userla
IGEP technology devices are TI OMAP3 SoC based industrial embedded
and computer-on-module boards. This patchset adds initial device
tree support for these devices.
The device trees allows to boot from an MMC and are working all the
components that already have device tree support on OMAP3 SoCs:
-
ISEE IGEPv2 is an TI OMAP3 SoC based embedded board.
This patch adds an initial device tree support to boot
an IGEPv2 from the MMC/SD.
Currently is working everything that is supported by DT
on OMAP3 SoCs (MMC/SD, GPIO LEDs, EEPROM, TWL4030 audio).
Signed-off-by: Javier Martinez Canillas
---
a
ISEE IGEP COM Module is an TI OMAP3 SoC computer on module.
This patch adds an initial device tree support to boot an
IGEP COM Module from the MMC/SD.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/omap3-igep0030.dts | 43 +
Add a generic .dtsi device tree source file for the
common characteristics across IGEP Technology devices.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/omap3-igep.dtsi | 93 +
1 files changed, 93 insertions(+), 0 deletions(-)
create mode 10
The seccomp path was using AUDIT_ANOM_ABEND from when seccomp mode 1
could only kill a process. While we still want to make sure an audit
record is forced on a kill, this should use a separate record type since
seccomp mode 2 introduces other behaviors. In the case of "handled"
behaviors (process w
On 11/29/2012 06:40 AM, Xiao Guangrong wrote:
> On 11/29/2012 05:57 AM, Marcelo Tosatti wrote:
>> On Wed, Nov 28, 2012 at 10:59:35PM +0800, Xiao Guangrong wrote:
>>> On 11/28/2012 10:12 PM, Gleb Natapov wrote:
On Tue, Nov 27, 2012 at 11:30:24AM +0800, Xiao Guangrong wrote:
> On 11/27/2012
Hi,
In realtime environments, it may be desirable to keep the per-bdi
flusher threads from running on certain cpus. This patch adds a
cpu_list file to /sys/class/bdi/* to enable this. The default is to tie
the flusher threads to the same numa node as the backing device (though
I could be convinc
Hi,
Due to unexplained dns problems, I'll be using google plus to post the
photo of the bug output.
https://plus.google.com/photos/110698868656495230656/albums/5816005854482735041
I'm sorry but my knowledge is limited and current caffeine level is low,
so I'm offloading to someone who has these
On Wednesday, November 28, 2012 03:10:46 PM Greg KH wrote:
> On Thu, Nov 29, 2012 at 12:05:20AM +0100, Rafael J. Wysocki wrote:
> > On Wednesday, November 28, 2012 02:46:33 PM Greg KH wrote:
> > > > So, it looks like the driver core wants us to handle driver unbinding no
> > > > matter what.
> > >
On Wed, 21 Nov 2012, Michal Hocko wrote:
> On Tue 20-11-12 13:49:32, Andrew Morton wrote:
> > On Mon, 19 Nov 2012 17:44:34 -0800 (PST)
> > David Rientjes wrote:
> >
> > > While profiling numa/core v16 with cgroup_disable=memory on the command
> > > line, I noticed mem_cgroup_count_vm_event() sti
On Wed, 28 Nov 2012 20:21:26 +0100
Thierry Reding wrote:
> + err = i2c_transfer(client->adapter, &msg, 1);
> + if (err < 0) {
> + /*
> + * If the time cannot be set, restart the RTC anyway. Note
> + * that errors are ignored if the RTC cannot be start
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Wednesday, November 28, 2012 5:43 PM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org
> Subject: Re: drivres/hv
>
> On Wed, Nov 28, 2012 at 12:17:30PM -0800, K. Y. Sriniva
On Wed, 2012-11-28 at 11:33 -0700, Stephen Warren wrote:
> Following this patch (http://lkml.org/lkml/2012/11/27/555), I posted a
> series of patches to convert almost all architectures to using the
> centralized rule. The one architecture I didn't convert was PowerPC.
>
> I didn't convert it bec
On Mon, Nov 19, 2012 at 11:00:12AM +, Kurachkin Michail wrote:
> Hi Greg,
>
> During the work on developing VoIP network router I designed TDM bus
> subsystem and wrote SLIC driver for si3226x. This code was developed for the
> commercial project, and now I am willing to release it under GPL
On Wed, 21 Nov 2012 19:52:41 -0500
Ed Cashin wrote:
> This patch series applies to today's linux-next/akpm, commit
> d3faae60d84f586ff8937b77c8476bca1b5f8ec6.
>
> Ed L. Cashin (8):
> aoe: copy fallback timing information on destination failover
> aoe: remove vestigial request queue allocatio
On Wednesday, November 28, 2012 02:02:48 PM Toshi Kani wrote:
> > > > > > > > Consider the following case:
> > > > > > > >
> > > > > > > > We hotremove the memory device by SCI and unbind it from the
> > > > > > > > driver at the same time:
> > > > > > > >
> > > > > > > > CPUa
On 11/28/2012 10:29 PM, Dan Carpenter wrote:
On Wed, Nov 28, 2012 at 08:30:04PM +0100, Sylwester Nawrocki wrote:
On 11/28/2012 01:22 PM, Dan Carpenter wrote:
In the end this is just a driver, and I don't especially care. But
it's like not just this one which makes me frustrated. I really
beli
On Wed, Nov 28, 2012 at 1:54 PM, H. Peter Anvin wrote:
> On 11/28/2012 01:47 PM, Yinghai Lu wrote:
>> rebase patchset on top of linus v3.7-rc4. this one replace patches in
>> tip/x86/mm2
>
> What are the changes? Given how close we are to the merge window, if we
> replace the entire patchset we
On Wed, 21 Nov 2012 23:09:46 +0800
Jiang Liu wrote:
> Subject: Re: [RFT PATCH v2 4/5] mm: provide more accurate estimation of pages
> occupied by memmap
How are people to test this? "does it boot"?
> If SPARSEMEM is enabled, it won't build page structures for
> non-existing pages (holes) with
On Wed, Nov 28, 2012 at 02:52:15PM -0800, Andrew Morton wrote:
> On Wed, 28 Nov 2012 10:13:59 +
> Mel Gorman wrote:
>
> > Based on the reports I've seen I expect the following to work for 3.7
> >
> > Keep
> > 96710098 mm: revert "mm: vmscan: scale number of pages reclaimed by
> > reclaim/
On Tue, Nov 27, 2012 at 6:49 AM, Justin Piszcz wrote:
>
>> It looks like maybe you don't have CONFIG_PCI_MMCONFIG turned on?
>
> ===> FOR I/OAT DMA
> Latest status, it _appears_ its working on the X9SRL-F now, thank you!
>
> 1) Supermicro X9SRL-F (GOOD)
> [0.738510] ioatdma: Intel(R) QuickData
On Wed, 21 Nov 2012 16:31:11 +0200
Andy Shevchenko wrote:
> When build a kernel with "make W=1" we will get a warning about missing
> initializer. It comes from kfifo usage style. The DEFINE_KFIFO macro doesn't
> initialize the buf[] field of the fifo structure. So, using C99 style helps in
> suc
On Wed, Nov 28, 2012 at 08:43:24AM -0800, Kent Overstreet wrote:
> Bunch of performance improvements and cleanups Zach Brown and I have
> been working on. The code should be pretty solid at this point, though
> it could of course use more review and testing.
Thanks for sending these out. I have s
This patch abolish:
[PATCH] tty: hold lock across tty buffer finding and buffer filling.
commit f8f72f047b96c6c8b13f6e3ba53fa6feb4266813
The commit f8f72f047 very dirty, has many degradation on SMP systems, because
take
spinlock at long time, and it doesn't resolve problem with
tty_prepare_strin
On Wed, Nov 28, 2012 at 11:32:52PM +, KY Srinivasan wrote:
> > > I recently discovered that the Hyper-V host allocates mmio
> > > memory for some synthetic devices like the virtual framebuffer.
> > > We are currently in the process of implementing this virtual
> > > framebuffer device. As part
Hi Mathias,
please note:
I'm writing this email on behalf of myself only and nobody else, especially not
my employer - and I'm doing this in my spare time.
I'm working for a direct competitor of yours, but I'm not using any knowledge
that I've picked up at work or that is considered secret in a
Hi Tejun,
I was bisecting a boot problem on a 32-bit NUMA kernel and it bisected
down to commit 8db78cc4. It turns out that, with this patch,
pcpu_need_numa() changed its return value on my system from 1 to 0.
What that basically meant was that we stopped using the remapped lowmem
areas for percp
On Wed, Nov 28, 2012 at 08:43:31AM -0800, Kent Overstreet wrote:
> Minor refactoring, to get rid of some duplicated code
A minor nit:
> spin_lock_irq(&ctx->ctx_lock);
> - ret = -EAGAIN;
> +
> kiocb = lookup_kiocb(ctx, iocb, key);
> - if (kiocb && kiocb->ki_cancel) {
> -
On Tue, Nov 27, 2012 at 7:35 AM, Justin Piszcz wrote:
>
>
> -Original Message-
> From: Justin Piszcz [mailto:jpis...@lucidpixels.com]
> Sent: Tuesday, November 27, 2012 8:56 AM
> To: 'Bjorn Helgaas'
> Cc: 'Bruno Prémont'; supp...@supermicro.com; linux-kernel@vger.kernel.org;
> 'Dan William
On Wed, 28 Nov 2012 23:54:12 +
Mel Gorman wrote:
> On Wed, Nov 28, 2012 at 02:52:15PM -0800, Andrew Morton wrote:
> > On Wed, 28 Nov 2012 10:13:59 +
> > Mel Gorman wrote:
> >
> > > Based on the reports I've seen I expect the following to work for 3.7
> > >
> > > Keep
> > > 96710098 m
On 11/28/2012 12:41 PM, Borislav Petkov wrote:
While at it, you could correct this comment to adhere to kernel coding
style:
/*
* cpuid is a barrier...
* ...
*/
+ asm volatile("cpuid" : "=a" (tmp) : "0" (1)
+: "ebx", "ecx", "edx", "
> struct kioctx {
> atomic_tusers;
> - int dead;
> + atomic_tdead;
Do we want to be paranoid and atomic_set() that to 0 when the ioctx is
allocated?
> + while (!list_empty(&ctx->active_reqs)) {
> + struct list_hea
501 - 600 of 820 matches
Mail list logo
