On Thu, 3 Jan 2013, Simon Jeons wrote:
On Wed, 2013-01-02 at 21:10 -0800, Hugh Dickins wrote:
As you can see, remove_rmap_item_from_tree uses it to decide whether
or not it should rb_erase the rmap_item from the unstable_tree.
Every full scan of all the rmap_items, we increment
On Sun, 16 Dec 2012, Linus Torvalds wrote:
On Wed, Dec 12, 2012 at 2:03 AM, Mel Gorman mgor...@suse.de wrote:
This is a pull request for Automatic NUMA Balancing V11. The list
Ok, guys, I've pulled this and pushed out. There were some conflicts
with both the VM changes and with the
provided, and may retain the write bit in the pmd.
Just move the BUG_ON(pmd_write(entry)) up into the !prot_numa block.
Signed-off-by: Hugh Dickins hu...@google.com
---
mm/huge_memory.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- 2a74dbb9/mm/huge_memory.c 2012-12-16 16
Offtopic...
On Thu, 15 Nov 2012, Jaegeuk Hanse wrote:
Another question. Why the function shmem_fallocate which you add to kernel
need call shmem_getpage?
Because shmem_getpage(_gfp) is where shmem's
page lookup and allocation complexities are handled.
I assume the question behind your
Further offtopic..
On Fri, 16 Nov 2012, Jaegeuk Hanse wrote:
Some questions about your shmem/tmpfs: misc and fallocate patchset.
- Since shmem_setattr can truncate tmpfs files, why need add another similar
codes in function shmem_fallocate? What's the trick?
I don't know if I understand
Sorry for taking so long to look at Petr's nice work: it's more than
what I can think through in odd stolen moments; but yesterday at last
I managed to get down to remembering KSM and giving this some time.
On Fri, 28 Sep 2012, Andrea Arcangeli wrote:
On Mon, Sep 24, 2012 at 02:56:06AM +0200,
Andrea's point about ksm_migrate_page() is an important one, and I've
answered that against his mail, but here's some other easier points.
On Mon, 24 Sep 2012, Petr Holasek wrote:
Introduces new sysfs boolean knob /sys/kernel/mm/ksm/merge_across_nodes
which control merging pages across
On Sun, 30 Sep 2012, Hugh Dickins wrote:
Andrea's point about ksm_migrate_page() is an important one, and I've
answered that against his mail, but here's some other easier points.
There's another point that I completely forgot to make once I got down
to the details of your patch.
Somewhere, I
Jan,
I noticed yesterday that the DirectMap counts at the bottom of x86_64's
/proc/meminfo are wrong on v3.5 and v3.6. For example, I happen to have
booted this laptop with mem=700M to run a test, but /proc/meminfo shows
DirectMap4k:4096 kB
DirectMap2M:18446744073709547520 kB
Or if
On Mon, 1 Oct 2012, Jamie Gloudon wrote:
Interesting. I am able to reproduce the same problem as you using mem=700M,
which shows:
DirectMap4k:4096 kB
DirectMap2M:18446744073709547520 kB
However, it appears to be normal without the boot parameter:
DirectMap4k:
Shaohua, Konstantin,
Sorry that it takes me so long to to reply on these swapin readahead
bounding threads, but I had to try some things out before jumping in,
and only found time to experiment last week.
On Thu, 6 Sep 2012, Konstantin Khlebnikov wrote:
This patch adds simple tracker for swapin
On Mon, 1 Oct 2012, Andrea Arcangeli wrote:
On Sun, Sep 30, 2012 at 05:36:33PM -0700, Hugh Dickins wrote:
I'm all for the simplest solution, but here in ksm_migrate_page()
is not a good place for COW breaking - we don't want to get into
an indefinite number of page allocations, and the risk
On Tue, 2 Oct 2012, Jan Beulich wrote:
On 01.10.12 at 10:37, Hugh Dickins hu...@google.com wrote:
I noticed yesterday that the DirectMap counts at the bottom of x86_64's
/proc/meminfo are wrong on v3.5 and v3.6. For example, I happen to have
booted this laptop with mem=700M to run a test
ext4_es_try_to_merge_left() to return whichever extent_status
should be recorded in tree-cache_es. Remove cache_es update from
both of them, leaving that to ext4_es_insert_extent()'s out label.
Signed-off-by: Hugh Dickins hu...@google.com
---
fs/ext4/extents_status.c | 15 +++
1 file changed, 7
On Tue, 2 Oct 2012, Shuah Khan wrote:
I started seeing the following null pointer dereference on
a linux-next sept 21 git and still seeing it on linux-next
Sep 27th git.
Can be reproduced easily. I have been able to reproduce every
time I do a complete build of a kernel on fresh checkout
On Tue, 2 Oct 2012, Andrew Morton wrote:
On Tue, 2 Oct 2012 15:10:56 -0700
Kees Cook keesc...@chromium.org wrote:
Has there been any more progress on this patch over-all?
No progress.
Al, Andrew, anyone? Thoughts on this?
(First email is https://lkml.org/lkml/2012/8/14/448)
On Sun, 6 Jan 2013, Hillf Danton wrote:
On Sat, Jan 5, 2013 at 11:22 PM, Dave Jones da...@redhat.com wrote:
I have no idea what happened here, but this is the first time I've seen
this one.
This was running a tree pulled yesterday afternoon.
BUG: unable to handle kernel paging request
On Sat, 5 Jan 2013, Sha Zhengju wrote:
On Wed, Jan 2, 2013 at 6:44 PM, Michal Hocko mho...@suse.cz wrote:
Maybe I have missed some other locking which would prevent this from
happening but the locking relations are really complicated in this area
so if
On Sun, 6 Jan 2013, Martin Mokrejs wrote:
I was running 3.7.1 kernel quite fine for a while but I realized that it is
slow and that
I should go and drop useless kernel drivers from my kernel. I have a
SandyBridge-based
laptop and I found that I gain speed while setting CONFIG_NO_HZ=y,
On Sun, 6 Jan 2013, Dave Jones wrote:
investigating the huge page theory a little further I'm a bit confused.
The kernel on that machine has THP enabled, and the cpu supports it (an old
amd64), but..
$ cat /sys/kernel/mm/hugepages/hugepages-2048kB/*
0
0
0
0
0
0
I was expecting at
On Mon, 7 Jan 2013, Simon Jeons wrote:
On Thu, 2013-01-03 at 13:24 +0100, Petr Holasek wrote:
Hi Simon,
On Mon, 31 Dec 2012, Simon Jeons wrote:
On Fri, 2012-12-28 at 02:32 +0100, Petr Holasek wrote:
v7: - added sysfs ABI documentation for KSM
Hi Petr,
How you
On Mon, 7 Jan 2013, Mel Gorman wrote:
Hugh Dickins pointed out that migrate_misplaced_transhuge_page() does not
check page_count before migrating like base page migration and khugepage. He
could not see why this was safe and he is right.
The potential impact of the bug is avoided due
On Tue, 8 Jan 2013, Andrea Arcangeli wrote:
Looking at this, one thing that isn't clear is where the page_count is
checked in migrate_misplaced_transhuge_page. Ok that it's unable to
migrate anon transhuge COW shared pages so it doesn't need to mess
with rmap (the mapcount check makes it
On Mon, 7 Jan 2013, Kamezawa Hiroyuki wrote:
(2013/01/07 5:02), Hugh Dickins wrote:
Forgive me, I must confess I'm no more than skimming this thread,
and don't like dumping unsigned-off patches on people; but thought
that on balance it might be more helpful than not if I offer you
On Wed, 9 Jan 2013, Mel Gorman wrote:
As pointed out by Hugh Dickins, mm: migrate: Check page_count of THP
before migrating can leave nr_isolated_anon elevated, correct it. This
is a fix to mm-migrate-check-page_count-of-thp-before-migrating.patch
Signed-off-by: Mel Gorman mgor...@suse.de
On Sat, 7 Jul 2007, Bob Tracy wrote:
Michal Piotrowski wrote:
On 05/07/07, Bob Tracy [EMAIL PROTECTED] wrote:
This happened on an Alpha computer (433au) running 2.6.22-rc6.
Can you reproduce this bug on 2.6.22-rc7-git6?
My guess is that you'll find yes.
The
error was
On Mon, 9 Jul 2007, Charles Shannon Hendrix wrote:
A system I was using a few minutes ago dumped this to the syslog:
Jul 9 17:50:38 daydream kernel: [76022.613000] BUG: unable to handle
kernel NULL pointer dereference at virtual address 0010
Jul 9 17:50:38 daydream kernel:
On Mon, 9 Jul 2007, Dave McCracken wrote:
On Monday 09 July 2007, Herbert van den Bergh wrote:
With this patch, not only memory in the data segment of a process, but
also private data mappings, both file-based and anonymous, are counted
toward the RLIMIT_DATA resource limit. Executable
On Mon, 9 Jul 2007, Dmitry Monakhov wrote:
Some device drivers can change vm_flags in their f_op-mmap
method. In order to be on the safe side we have to recheck
lock rlimit. Now we have to check lock rlimit from two places,
let's move this common code to helper functon.
Signed-off-by:
On Tue, 10 Jul 2007, Dave McCracken wrote:
On Tuesday 10 July 2007, Hugh Dickins wrote:
This brings the Linux behavior in line with what is documented in the
POSIX man page for setrlimit(3p).
Which says malloc() can fail from it, but conspicuously not that mmap()
can fail from
On Tue, 10 Jul 2007, Dave McCracken wrote:
On Tuesday 10 July 2007, Hugh Dickins wrote:
Mapped private readonly yes, but vm_stat_account() says
if (file) {
mm-shared_vm += pages;
if ((flags (VM_EXEC|VM_WRITE)) == VM_EXEC)
mm-exec_vm
On Tue, 10 Jul 2007, Dmitry Monakhov wrote:
On 18:27 Втр 10 Июл , Hugh Dickins wrote:
Or would this simpler patch be the right one? I suspect the
mspec driver only says VM_LOCKED because of a deep-seated but
irrational fear that its pages might fall into reclaim.
No mspec
On Mon, 9 Jul 2007, William Tambe wrote:
Hugh Dickins wrote:
I've come right around to your original view, Stas, and William's:
if that mmap creates such an object, then the expanding mremap really
ought to be useful, and allow the underlying object to be expanded.
The shared anonymous
On Mon, 9 Jul 2007, Bob Tracy wrote:
--- 2.6.22-rc7/arch/alpha/kernel/pci_iommu.c2007-06-05
06:19:19.0 +0100
+++ linux/arch/alpha/kernel/pci_iommu.c 2007-07-07 15:00:04.0
+0100
That seems to have done the trick. Normally, I get the bad page
errors on
On Wed, 11 Jul 2007, Jens Axboe wrote:
On Tue, Jul 10 2007, Andrew Morton wrote:
On Tue, 10 Jul 2007 23:00:59 GMT Linux Kernel Mailing List
linux-kernel@vger.kernel.org wrote:
+static int shmem_readpage(struct file *file, struct page *page)
+{
+ struct inode *inode =
On Wed, 11 Jul 2007, Ivan Kokshaysky wrote:
On Tue, Jul 10, 2007 at 09:25:50PM +0100, Hugh Dickins wrote:
On Mon, 9 Jul 2007, Bob Tracy wrote:
That seems to have done the trick. Normally, I get the bad page
errors on the second NX session, but I'm on the third session of the
day (thus
On Wed, 11 Jul 2007, Christoph Hellwig wrote:
On Wed, Jul 11, 2007 at 02:12:45PM +0400, Dmitry Monakhov wrote:
Or would this simpler patch be the right one? I suspect the
mspec driver only says VM_LOCKED because of a deep-seated but
irrational fear that its pages might fall into
On Wed, 11 Jul 2007, Jes Sorensen wrote:
Hugh Dickins wrote:
Or would this simpler patch be the right one? I suspect the
mspec driver only says VM_LOCKED because of a deep-seated but
irrational fear that its pages might fall into reclaim.
My mind is rusty on this one, so I checked
On Thu, 12 Jul 2007, Ivan Kokshaysky wrote:
On Wed, Jul 11, 2007 at 06:07:59PM +0100, Hugh Dickins wrote:
+ return __pci_alloc_consistent(dev, size, dma, GFP_ATOMIC);
I was going to ask you why that needs to be GFP_ATOMIC on Alpha.
But find you're following the example of asm-generic
On Thu, 12 Jul 2007, Marcos David wrote:
Hi,
I´m using RedHat Enterprise Server 4 Update 3 (kernel 2.6.9-34.ELsmp)
I was listing the contents of /proc/pid/status file and I came up with
a value of:
...
VmLib: 4294948464 kB,
...
Is this a known bug?
the process in question uses a lot
On Fri, 13 Jul 2007, Andrew Morton wrote:
On Mon, 9 Jul 2007 22:49:17 +0400 Dmitry Monakhov [EMAIL PROTECTED] wrote:
Some device drivers can change vm_flags in their f_op-mmap
method. In order to be on the safe side we have to recheck
lock rlimit. Now we have to check lock rlimit from two
On Tue, 10 Jul 2007, Herbert van den Bergh wrote:
Hugh Dickins wrote:
On Tue, 10 Jul 2007, Dave McCracken wrote:
On Tuesday 10 July 2007, Hugh Dickins wrote:
Mapped private readonly yes, but vm_stat_account() says
if (file) {
mm-shared_vm += pages;
if ((flags
On Wed, 13 Jun 2007, Dmitriy Monakhov wrote:
loop.c code itself is not perfect. In fact before Nick's patch
partial write was't possible. Assumption what write chunks are
always page aligned is realy weird ( see index++ line).
Signed-off-by: Dmitriy Monakhov [EMAIL
On Wed, 13 Jun 2007, Dmitriy Monakhov wrote:
Btw: Nick's patches broke LO_CRYPT_XOR mode,
It would help him if you could describe how.
but it is ok because
this feature was absolete and not used by anyone, am i right here?
I know nothing of this; but so long as its code remains in the
set.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
That #ifdef I've put in there is not essential:
it's perhaps more of a comment or an accusation ;)
include/linux/mm.h |4
1 file changed, 4 insertions(+)
--- 2.6.22-rc5/include/linux/mm.h 2007-05-26 07:16:48.0 +0100
On Thu, 21 Jun 2007, Christoph Lameter wrote:
On Thu, 21 Jun 2007, Hugh Dickins wrote:
The oops seems to occur after a page unmapping using dma_unmap_page()
followed
by a flush_dcache_page() (in at91mci_post_dma_read()).
Was the page allocated using slab calls?
You've found yes
On Thu, 21 Jun 2007, Christoph Lameter wrote:
Maybe this will address the issue on ARM?
Looks like it would indeed address the immediate issue on ARM -
IF they've no particular reason to be using kmalloc there.
However... what gives you confidence that flush_dcache_page is
never applied to
On Thu, 21 Jun 2007, Christoph Lameter wrote:
On Thu, 21 Jun 2007, Hugh Dickins wrote:
Seems a little odd that it's gone throughout 2.6.22-rc unnoticed
until now - nobody else trying SLUB on ARM or PA-RISC yet perhaps.
The impact is only on a subset of ARM machines.
PA_RISC? It looks
On Thu, 21 Jun 2007, Christoph Lameter wrote:
On Fri, 22 Jun 2007, Hugh Dickins wrote:
However... what gives you confidence that flush_dcache_page is
never applied to other slab pages?
Flush dcache page is supposed to run on pages not objects of varying
length. It is suprising
On Fri, 22 Jun 2007, Marc Pignat wrote:
from: Marc Pignat [EMAIL PROTECTED]
kunmap must be called on the pointer returned by kmap.
Not necessarily: an offset within the same page is acceptable.
Signed-off-by: Marc Pignat [EMAIL PROTECTED]
---
N.B: This is the same patch as
On Fri, 22 Jun 2007, Nicolas Ferre wrote:
Here:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b9bae3402572dc50a1e084c5b1ae5117918ef0f0
Yup.
But it would be good to hear from Nicolas whether that indeed fixes
his oops: I couldn't actually try my patch on
On Fri, 22 Jun 2007, Christoph Lameter wrote:
Add VM_BUG_ON in case someone uses page_mapping on a slab page
Detect slab objects being passed to the page oriented functions of the VM.
It is not sufficient to simply return NULL because the functions calling
page_mapping may depend on
On Fri, 22 Jun 2007, Christoph Lameter wrote:
On Fri, 22 Jun 2007, Hugh Dickins wrote:
I'm quite happy with this approach for 2.6.23-rc, along with your ARM
dma_map patch which (if I understood aright) rmk approved. Except,
haven't you misplaced that VM_BUG_ON between an if and its else
On Fri, 22 Jun 2007, Christoph Lameter wrote:
We need to fix any remaining weird slab object uses right now. Your check
leaves a lot of holes open. 2.6.22 removes all other such strange slab
uses in other arches. It would be inconsistent if we left these things in
ARM (and maybe PA-RISC).
On Sun, 24 Jun 2007, Russell King wrote:
On Fri, Jun 22, 2007 at 07:39:33PM +0100, Hugh Dickins wrote:
I'm quite happy with this approach for 2.6.23-rc, along with your ARM
dma_map patch which (if I understood aright) rmk approved.
I didn't approve it. Please re-read my reply
On Sun, 24 Jun 2007, Russell King wrote:
On Sun, Jun 24, 2007 at 11:24:16AM +0100, Hugh Dickins wrote:
On Sun, 24 Jun 2007, Russell King wrote:
On Fri, Jun 22, 2007 at 07:39:33PM +0100, Hugh Dickins wrote:
Please forward the original problem report.
Done.
Okay, that seems
On Thu, 31 May 2007, Jens Axboe wrote:
This patch removes the -sendfile() hook from the file_operations
structure, and replaces the sys_sendfile() mechanism to be based on
-splice_read() instead. There should be no functional changes.
Work to be done:
- The ext2 xip support needs a
On Mon, 25 Jun 2007, Christoph Lameter wrote:
On Mon, 25 Jun 2007, Hugh Dickins wrote:
And I now rather think that needs to stay, not be replaced by the
VM_BUG_ON Christoph was proposing for 2.6.23 (which earlier I acked).
Christoph responded to my page_mapping patch by looking at arch
On Mon, 25 Jun 2007, Christoph Lameter wrote:
On Mon, 25 Jun 2007, Hugh Dickins wrote:
In many situations the page struct passed to flush_dcache_page is
simply used to calculate the virtual address. So its mostly harmless.
Trouble starts when page attributes like the mapping is used
On Mon, 25 Jun 2007, Christoph Lameter wrote:
On Mon, 25 Jun 2007, Hugh Dickins wrote:
I didn't claim that flush_dcache_page(virt_to_page(virt)) is not expected
to work. I claim that flush_dcache_page is expected to be a noop rather
than an oops on a kmalloced page
On Mon, 25 Jun 2007, Christoph Lameter wrote:
On Mon, 25 Jun 2007, Hugh Dickins wrote:
The sometimes we have kmalloced buffers locations need to be fixed.
I've said enough, I'd better leave it to others to deter you or not
from fiddling around pointlessly here.
Are there any
.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
mm/rmap.c | 24 +---
1 file changed, 1 insertion(+), 23 deletions(-)
--- 2.6.22-rc6/mm/rmap.c2007-05-19 07:36:34.0 +0100
+++ linux/mm/rmap.c 2007-06-25 21:01:01.0 +0100
@@ -53,24 +53,6
On Tue, 26 Jun 2007, Thomas Sattler wrote:
Hi there ...
I removed xfs from my system. The first reboot after replacing xfs with
ext3 brought be
Perhaps this is a curse that falls on those who desert XFS ;)
Jun 26 08:43:17 pearl =
Jun 26 08:43:17 pearl [ BUG:
On Tue, 26 Jun 2007, Ulrich Drepper wrote:
On 6/26/07, Davide Libenzi [EMAIL PROTECTED] wrote:
OTOH glibc could implement __morecore using mmap(MAP_NOZERO), and hence
brk2() would not be needed, no?
No. mmap calls create individual VMAs which gets expensive. There
are also some
On Wed, 27 Jun 2007, Ulrich Drepper wrote:
On 6/27/07, Hugh Dickins [EMAIL PROTECTED] wrote:
Not so: if an mmap can be done by extending either adjacent vma (prot
and flags and file and offset all match up), that's what's done and no
separate vma is created. (And adjacent vmas get merged
On Wed, 27 Jun 2007, Davide Libenzi wrote:
On Wed, 27 Jun 2007, Hugh Dickins wrote:
In honesty, I should add that I dislike and distrust Davide's
MAP_NOZERO very much indeed! Would much rather leave my cpus
spending a little time in clear_page(). A uid in struct page
(though I'm sure
On Wed, 27 Jun 2007, Casey Leedom wrote:
I'm working on a driver that does a get_user_pages() for a DMA write. We
have a timeout on the DMA completion where we mark the pages as COW and return
to the application so it can potentially generate more data in order to
increase throughput,
On Wed, 27 Jun 2007, Ulrich Drepper wrote:
On 6/27/07, Hugh Dickins [EMAIL PROTECTED] wrote:
The absolute virtual addresses are randomized, yes; but do a sequence
of mmaps and they come back adjacent to each other, and so mergable.
Or does your distro include a kernel patch to randomize
On Thu, 28 Jun 2007, Christoph Lameter wrote:
I had a talk with James Bottomley last night and it seems that there is an
established way of using the page structs of slab objects in the block
layer. Drivers may use the DMA interfaces to issue control commands. In
that case they may
I don't dare comment on your page_mkclean_one patch (5/5),
that dirty page business has grown too subtle for me.
Your cleanups 2-4 look good, especially the mm_types.h one (how
confident are you that everything builds?), and I'm glad we can
now lay ptep_establish to rest. Though I think you may
On Fri, 29 Jun 2007, Martin Schwidefsky wrote:
On Fri, 2007-06-29 at 19:56 +0100, Hugh Dickins wrote:
I don't dare comment on your page_mkclean_one patch (5/5),
that dirty page business has grown too subtle for me.
Oh yes, the dirty handling is tricky
I'll move that discussion over
On Fri, 29 Jun 2007, Martin Schwidefsky wrote:
On Fri, 2007-06-29 at 19:56 +0100, Hugh Dickins wrote:
I don't dare comment on your page_mkclean_one patch (5/5),
that dirty page business has grown too subtle for me.
Oh yes, the dirty handling is tricky. I had to fix a really nasty bug
On Sun, 1 Jul 2007, Martin Schwidefsky wrote:
Expect you're right, but I _really_ don't want to comment, when I don't
understand that || pte_write in the first place, and don't know the
consequence of pte_dirty !pte_write or !pte_dirty pte_write there.
The pte_write() part is for the
On Fri, 29 Jun 2007, William Tambe wrote:
I read a post that you made about not being able to expand anonymous shared
mapping with mremap(). And I am actually having that issue now.
I guess you're referring to the thread at
http://lkml.org/lkml/2004/6/16/155
and you're asking either Stas or
On Mon, 2 Jul 2007, Stas Sergeev wrote:
Hugh Dickins wrote:
You've answered your own question: we did not make the change Stas
suggested, IIRC because I remained a little uneasy with that change
in behaviour, and nobody else spoke up for it.
IIRC your argument, that made sense to me
]
Acked-by: Hugh Dickins [EMAIL PROTECTED]
(Looking at it, I see that we could argue that there ought to be a
need_resched() etc. check after your tlb_flush_mmu() in unmap_vmas,
in case it's spent a long while in there on some arches; but I don't
think we have the ZAP_BLOCK_SIZE tuned with any
On Tue, 3 Jul 2007, Martin Schwidefsky wrote:
+
+static inline struct mmu_gather *tlb_gather_mmu(struct mm_struct *mm,
+ unsigned int full_mm_flush)
+{
+ struct mmu_gather *tlb = get_cpu_var(mmu_gathers);
+
+ tlb-mm = mm;
+ tlb-fullmm
check for safety, though failure may well be impossible.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
fs/compat_ioctl.c | 33 +
1 file changed, 25 insertions(+), 8 deletions(-)
--- 2.6.22-rc2/fs/compat_ioctl.c2007-05-13 05:40:57.0 +0100
On Mon, 21 May 2007, Martin Drab wrote:
On Tue, 13 Mar 2007, Hugh Dickins wrote:
On Fri, 9 Mar 2007, Martin Drab wrote:
Hi Martin, sorry for joining so late.
Hi, Hugh, this time I'm sorry for responding sooo late.
Ditto.
And preface: I'm a lousy person to be advising on driver writing
On Wed, 30 May 2007, KAMEZAWA Hiroyuki wrote:
This is my latest version.
(not tested because caller of this function is being rewritten now..)
I'll move this patch to the top of my series and prepare to post this patch as
a single patch.
==
page migration by kernel v2.
Changelog V1 -
On Thu, 12 Jul 2007, Andrew Morton wrote:
It'd be much better to fix the race within alloc_fresh_huge_page(). That
function is pretty pathetic.
Something like this?
--- a/mm/hugetlb.c~a
+++ a/mm/hugetlb.c
@@ -105,13 +105,20 @@ static void free_huge_page(struct page *
static int
On Tue, 17 Jul 2007, Andrew Morton wrote:
On Tue, 17 Jul 2007 16:04:54 +0100 (BST) Hugh Dickins [EMAIL PROTECTED]
wrote:
On Thu, 12 Jul 2007, Andrew Morton wrote:
It'd be much better to fix the race within alloc_fresh_huge_page(). That
function is pretty pathetic.
Something
On Tue, 17 Jul 2007, Andrew Morton wrote:
On Tue, 17 Jul 2007 18:26:14 +0100 (BST) Hugh Dickins [EMAIL PROTECTED]
wrote:
I think I like the lock ;)
I hate to waste your time, but I'm still puzzled. Wasn't the race fixed
by your changeover from use of static int nid throughout
strictly. Kill nid_lock.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
mm/hugetlb.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
--- 2.6.22-git9/mm/hugetlb.c2007-07-17 20:29:33.0 +0100
+++ linux/mm/hugetlb.c 2007-07-17 21:29:58.0 +0100
@@ -107,15
Code: 49 83 7c 24 08 00 75 0e 48 c7 44 24 08 00 00 00 00 e9 6a 02
RIP [8105d4e7] __alloc_pages+0x2f/0x2c3
RSP 810071563e48
CR2: 186a
From your patch, if we dont the lock, the race condition maybe occur at
next_node().
On 2007-07-17 21:35, Hugh Dickins wrote
On Wed, 18 Jul 2007, Joe Jin wrote:
Sorry for I use a unclean kernel tree, the panic have gone ;)
also, I will testing it again with other server, if I hit it I'll let you
know.
That's a relief! Thanks,
Hugh
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Wed, 18 Jul 2007, Jens Axboe wrote:
We have these checks scattered, makes sense to put them in
set_page_dirty() instead. This also fixes a bug where __bio_unmap_user()
does set_page_dirty_lock() without checking for a compound page, instead
of adding one more check we move it to
On Wed, 18 Jul 2007, Jens Axboe wrote:
OK, you clearly have more knowledge in that area than I, but I do wish
that you would have made a note in the code at least to remove things
like this. It's pretty ugly to have superflous tests like that,
especially since there was not even a comment
On Wed, 18 Jul 2007, Jens Axboe wrote:
Since I had my hands dirty already...
Great, thanks. (There's also such a test in fs/nfs/direct.c,
but let's not trouble Trond until we've settled what to do here.)
---
[PATCH] Remove PageCompound() checks before calling set_page_dirty()
Pre
On Thu, 19 Jul 2007, Jens Axboe wrote:
On Wed, Jul 18 2007, Hugh Dickins wrote:
On Wed, 18 Jul 2007, Jens Axboe wrote:
Since I had my hands dirty already...
Great, thanks. (There's also such a test in fs/nfs/direct.c,
but let's not trouble Trond until we've settled what to do
On Tue, 8 May 2007, Nick Piggin wrote:
This patch trades a page flag for a significant improvement in the unlock_page
fastpath. Various problems in the previous version were spotted by Hugh and
Ben (and fixed in this one).
Comments?
Seems there's still a bug there. I get hangs on the page
On Wed, 9 May 2007, Nick Piggin wrote:
Hugh Dickins wrote:
On Wed, 2 May 2007, Nick Piggin wrote:
But I'm pretty sure (to use your words!) regular truncate was not racy
before: I believe Andrea's sequence count was handling that case fine,
without a second unmap_mapping_range
On Thu, 10 May 2007, Nick Piggin wrote:
The filesystem (or page cache) allows pages beyond i_size to come
in there? That wasn't a problem before, was it? But now it is?
The filesystem still doesn't, but if i_size is updated after the page
is returned, we can have a problem that was
to delete
your CONFIG_SLAB=y to get Kconfig to offer you the choice of SLUB now.
powerpc: Don't use SLAB/SLUB for PTE pages
From: Hugh Dickins [EMAIL PROTECTED]
The SLUB allocator relies on struct page fields first_page and slab,
overwritten by ptl when SPLIT_PTLOCK: so the SLUB allocator cannot
On Fri, 4 May 2007, Ulrich Drepper wrote:
I don't want to judge the numbers since I cannot but I want to make an
observations: even if in the SMP case MADV_FREE turns out to not be a
bigger boost then there is still the UP case to keep in mind where Rik
measured a significant speed-up. As
On Wed, 9 May 2007, Nick Piggin wrote:
On Wed, May 09, 2007 at 12:41:24AM +0200, Nick Piggin wrote:
On Wed, May 09, 2007 at 07:30:27AM +1000, Benjamin Herrenschmidt wrote:
Waking them all would fix it but at the risk of causing other
problems... Maybe PG_waiters need to actually be a
On Thu, 10 May 2007, Nick Piggin wrote:
OK, I found a simple bug after pulling out my hair for a while :)
With this, a 4-way system survives a couple of concurrent make -j250s
quite nicely (wheras they eventually locked up before).
The problem is that the bit wakeup function did not go
Just want to report that I've been running SLUB on i386, both in -mm
and with slub-i386-support.patch applied to 2.6.21-git, and observed
no problems with it. I'm anxious that it (or an equivalent) go into
2.6.22-rc1, i386 being now the last ARCH_USES_SLAB_PAGE_STRUCT holdout.
In the frenzy over
On Thu, 10 May 2007, William Lee Irwin III wrote:
On Thu, May 10, 2007 at 09:03:39PM +0100, Hugh Dickins wrote:
Though when I look at the patchset (copied below), I do wonder why
it puts a quicklist_trim() into i386's cpu_idle() and flush_tlb_mm():
neither is where I'd expect us
On Fri, 11 May 2007, Andrew Morton wrote:
On Fri, 11 May 2007 10:29:30 +0200 Andi Kleen [EMAIL PROTECTED] wrote:
I'm guessing (haven't rechecked source) that the cpu_idle() call comes
about because the top level pgd of a process gets freed very late in
its exit, and after a great
901 - 1000 of 4042 matches
Mail list logo
