groups_sort() can be quite long if user loads a large gid table.
This is because GROUP_AT(group_info, some_integer) uses an integer divide.
So having to do XXX thousand divides during one syscall can lead to very high
latencies. (NGROUPS_MAX=65536)
In the past (25 Mar 2006), an analog problem
On Tue, 11 Dec 2007 21:05:10 +0100
Daniel Ritz <[EMAIL PROTECTED]> wrote:
> [PATCH] usbtouchscreen: fix buffer overflow, make more egalax work
>
> fixes a buffer overflow in mutli-packet handling code. the overflow can only
> happen with eGalax devices and is even there very unlikely (only
Linus Torvalds wrote:
On Tue, 18 Dec 2007, Richard Henderson wrote:
I've added dmesg, /proc/iomem, and lspci -v output to that bug.
Basically, we have
c000-cfff : free
ddf0-dfef : PCI Bus #04
e000-efff : pnp 00:0b
f000-fedf :
On Tue, 11 Dec 2007 16:38:46 +0100
[EMAIL PROTECTED] wrote:
> [PATCH 01/02]
>
> This patch computes msg_ctlmni to make it scale with system memory.
> msg_ctlmni is now set to make the message queues occupy 1/32 of the available
> memory.
>
> Some cleaning has also been done in the MSGXXX
Add debugfs_create_s{8,16,32,64}. For these to work properly, we need to
remove a cast in libfs.
Cc: Johannes Berg <[EMAIL PROTECTED]>
To: Greg Kroah-Hartman <[EMAIL PROTECTED]>
Signed-off-by: Stefano Brivio <[EMAIL PROTECTED]>
---
Greg,
here comes an implementation of
shashi59 wrote:
I am newbie for Linux Kernel.How can I read the memory area like the range
between to .Directly i read that area it shows some error
like this "unable to handle kernel paging request at virtual address
". So,I don't know, how to solve this error .Please
Karsten Wiese wrote:
Hi,
while playing with jackd on 2.6.24-rcx, I found poll() timing out too early.
That is: earlier than its timeout argument specified.
Setting poll()'s timeout argument to "required timeout" + "1 jiffy in ms"
fixed it. Patch below should fix it too. Correct?
Untested.
On Tue 18-12-07 14:50:07, Mark Fasheh wrote:
> On Tue, Dec 18, 2007 at 04:25:05PM +0100, Jan Kara wrote:
> > Although we don't allow writes over s_maxbytes, it can happen that a file's
> > size is larger than s_maxbytes. For example we can write the file from
> > a computer with a different
On Tue, Dec 18, 2007 at 07:50:33PM +0800, Fengguang Wu wrote:
> On Tue, Dec 18, 2007 at 09:19:07AM +0100, Nick Piggin wrote:
> > On Sun, Dec 16, 2007 at 07:59:30PM +0800, Fengguang Wu wrote:
>
> > > + read_lock_irq(>tree_lock);
> > > + page = radix_tree_lookup(>page_tree, offset);
> > > + if
It appears that this patch is missing from the latest 2.6.24 git
kernel as well as the 2.6.24-rc5-mm1 patch?
> Mike, This issue still seems to be present in linus git tree. Perhaps
> the fix in -mm not pushed to mainline yet.
>
> Can you please raise the flag with Andrew, so that he can push it
Matt Mackall wrote:
Blech. Invoking the random pool machinery at oops time is moderately
safe, but not very shiny. Going through all the sprintf ugliness to
format it to an irrelevant UUID standard is not very shiny either. At
least refactor it so it's not duplicating code.
And I'd much rather
It appears that this patch is missing from the latest 2.6.24 git
kernel as well as the 2.6.24-rc5-mm1 patch?
> Mike, This issue still seems to be present in linus git tree. Perhaps
> the fix in -mm not pushed to mainline yet.
>
> Can you please raise the flag with Andrew, so that he can push it
This fix corrects the problem that early_identify_cpu() sets
cpu_index to '0' (needed when called by setup_arch) after
smp_store_cpu_info() had set it to the correct value.
The error shows up in 'cat /proc/cpuinfo' will all cpus = 0.
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
On Sun, 9 Dec 2007 22:23:42 +0100
Marcin __lusarz <[EMAIL PROTECTED]> wrote:
> usb/storage/initializers.c: fix signedness difference
>
> Signed-off-by: Marcin __lusarz <[EMAIL PROTECTED]>
> ---
> drivers/usb/storage/initializers.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
>> This patch removes some redundant code in the function setup_sigcontext().
>>
>> The registers ar.ccv,b7,r14,ar.csd,ar.ssd,r2-r3 and r16-r31 are not restored
>> in restore_sigcontext() when (flags & IA64_SC_FLAG_IN_SYSCALL) is true.
>> So we don't need to zero those variables in
Kprobe reenter logic from deeply indented section to helper function.
This improves code readability.
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
Signed-off-by: Masami Hiramatsu <[EMAIL
Fix a preemption bug in kprobe_handler(). It has to call preempt_enable()
before returning.
I think this is critical on preemptive kernel.
Signed-off-by: Masami Hiramatsu <[EMAIL PROTECTED]>
---
arch/x86/kernel/kprobes.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Index:
On Tue, Dec 18, 2007 at 04:46:09PM -0500, Chuck Ebbert wrote:
> pnpacpi=off should work.
This does result in the graphics bar being placed at e000,
and does result in a system lockup when X starts. So it appears
as if there's really something there.
r~
--
To unsubscribe from this list:
On 12/18/2007 06:06 PM, Haavard Skinnemoen wrote:
> From: Remy Bohmer <[EMAIL PROTECTED]>
>
> This patch splits up the interrupt handler of the serial port
> into a interrupt top-half and a tasklet.
[...]
> [EMAIL PROTECTED]: misc cleanups and simplifications]
> Signed-off-by: Remy Bohmer <[EMAIL
Steve Davies <[EMAIL PROTECTED]> :
[...]
> I assume that the NIC is not allowing tagged packets into the driver
> due to its built-in hardware acceleration/filtering :(
>
> Is it inappropriate to beg for help and suggestions?
Try to disable the vlan related Rx filtering ?
--
Ueimor
--
To
On Tue, Dec 18, 2007 at 11:00:16PM +, Al Viro wrote:
> On Tue, Dec 18, 2007 at 05:46:21PM -0500, Mark Lord wrote:
> > Why does link(2) not support hard-linking across bind mount points
> > of the same underlying filesystem ?
>
> Because it gives you a security boundary around a subtree.
PS:
In message <[EMAIL PROTECTED]>, Hugh Dickins writes:
> In order to fix unionfs truncation, we need to move the lower notify_change
> out of the loop in unionfs_setattr. But when I came to do that, I couldn't
[...]
Hugh, I want to understand how patches 3/4 and 4/4 are related. In patch 3
you
On Tue, Dec 18, 2007 at 05:46:21PM -0500, Mark Lord wrote:
> Why does link(2) not support hard-linking across bind mount points
> of the same underlying filesystem ?
Because it gives you a security boundary around a subtree.
--
To unsubscribe from this list: send the line "unsubscribe
Mark Lord wrote:
Why does link(2) not support hard-linking across bind mount points
of the same underlying filesystem ?
Is it as simple as something like this patch below (minus the printk)?
Not likely, but then I'm not a filesystem guru.
???
--- old/fs/namei.c2007-12-15
In message <[EMAIL PROTECTED]>, Hugh Dickins writes:
> redirty:
> set_page_dirty(page);
> - return AOP_WRITEPAGE_ACTIVATE; /* Return with the page locked */
> + if (wbc->for_reclaim)
> + return AOP_WRITEPAGE_ACTIVATE; /* Return with page locked */
> +
On Tue, Dec 18, 2007 at 04:25:05PM +0100, Jan Kara wrote:
> Although we don't allow writes over s_maxbytes, it can happen that a file's
> size is larger than s_maxbytes. For example we can write the file from
> a computer with a different architecture (which has larger s_maxbytes),
> boot a kernel
On Wed, Dec 19, 2007 at 12:09:46AM +0200, Alon Bar-Lev wrote:
> On 12/18/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> > Make sure your /init doesn't depend on an interpreter or library which
> > isn't available.
>
> Thank you for your answer.
>
> I already checked.
>
> /init is hardlink to
diff --git a/Makefile b/Makefile
index ada10d5..96c3f02 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 23
-EXTRAVERSION = .11
+EXTRAVERSION = .12
NAME = Arr Matey! A Hairy Bilge Rat!
# *DOCUMENTATION*
diff --git a/drivers/pnp/pnpacpi/rsparser.c
We (the -stable team) are announcing the release of the 2.6.23.12 kernel.
It just reverts one patch that has been causing some users some
problems. For details about the problems, see:
http://bugzilla.kernel.org/show_bug.cgi?id=9514
If you are not having any problems with the 2.6.23.11
Why does link(2) not support hard-linking across bind mount points
of the same underlying filesystem ?
Is it as simple as something like this patch below (minus the printk)?
Not likely, but then I'm not a filesystem guru.
???
--- old/fs/namei.c 2007-12-15 12:33:13.0 -0500
+++
On Tue, 18 Dec 2007, Richard Henderson wrote:
>
> Another way to look at this is that the graphics BAR came in from
> the BIOS allocated at c000, and we ignored that.
We did?
> Perhaps there's a way to give weight to the BIOS settings when
> consdering where the PCI region is supposed to
From: Stefan Richter <[EMAIL PROTECTED]>
Date: Tue, 18 Dec 2007 11:38:27 +0100
> - There has been no other report of this kind for any other
> architecture yet. I would expect e.g. the PPC64 folks to report
> bugs in our dma mappings eventually.
Irrelevant fact, powerpc handles it's
From: Stefan Richter <[EMAIL PROTECTED]>
Date: Tue, 18 Dec 2007 11:38:27 +0100
> Also note:
> - The very same code did not oops at this point in 2.6.22. It only
> started doing so in 2.6.23.
2.6.23 is when the sparc64 IOMMU code started relying upon
the dev_archdata bits being correct.
--
The memcgroup regime relies upon a cgroup reclaiming pages from itself
within add_to_page_cache: which may involve some waiting. Whereas shmem
and tmpfs rely upon using add_to_page_cache while holding a spinlock:
when it cannot wait. The consequence is that when a cgroup reaches its
limit,
On Tue, Dec 18, 2007 at 10:25:50PM +0100, Eric Dumazet wrote:
> Some 'extern struct seq_operations' are wrongly defined in
> fs/proc/proc_misc.c (they miss a const qualifier)
>
> In order to fix this correctly, move the "extern ... " declaration from .c
> file to an appropriate include file, as
Tidy up mem_cgroup_charge_common before extending it. Adjust some
comments, but mainly clean up its loop: I've an aversion to loops
full of continues, then a break or a goto at the bottom. And the
is_atomic test should be on the __GFP_WAIT bit, not GFP_ATOMIC bits.
Signed-off-by: Hugh Dickins
Here's a couple of patches to get memcgroups working better with tmpfs
and shmem, in conjunction with the tmpfs patches I just posted. There
will be another to come later on, but I shouldn't wait any longer to get
these out to you.
(The missing patch will want to leave a mem_cgroup associated
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> Booting RHEL 5 i386 in kvm with -no-kvm-irqchip -smp 4 will hang in udev.
> I bisected this to a change in the _guest_ kernel:
>
>> commit 95492e4646e5de8b43d9a7908d6177fb737b61f0
>> Author: Ingo Molnar <[EMAIL PROTECTED]>
>> Date: Fri Feb 16
fsx-linux in a unionfs soon fails (with oops on tmpfs): truncation doesn't
work right.
When shrinking a file, unionfs_setattr needs to vmtruncate the upper level
before notifying change to the lower level, to eliminate those dirty pages
beyond new eof which otherwise drift down to the lower
Alon Bar-Lev wrote:
On 12/18/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Make sure your /init doesn't depend on an interpreter or library which
isn't available.
Thank you for your answer.
I already checked.
/init is hardlink to busybox, it depends on libc.so.0 which is available at /lib
LTP's iogen01 doio tests hang nicely on 32-bit SMP when /tmp is a unionfs
mount of a tmpfs. See the comment on i_size_write in linux/fs.h: it needs
to be locked, otherwise i_size_read can spin forever waiting for a lost
seqcount update.
Most filesystems are already holding i_mutex for this, but
In order to fix unionfs truncation, we need to move the lower notify_change
out of the loop in unionfs_setattr. But when I came to do that, I couldn't
understand that loop at all: its continues and breaks and gotos are obscure,
most particularly the "if (copyup || (bindex != bstart)) continue;"
Remove !mapping_cap_writeback_dirty shortcircuit from unionfs_writepages.
It was introduced to avoid the stray AOP_WRITEPAGE_ACTIVATE coming from
shmem_writepage; but that has since been fixed in shmem_writepage and in
write_cache_pages. It stayed because it looked like a good optimization,
not
On 12/18/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> Make sure your /init doesn't depend on an interpreter or library which
> isn't available.
Thank you for your answer.
I already checked.
/init is hardlink to busybox, it depends on libc.so.0 which is available at /lib
But shouldn't I get
Here's a few patches to unionfs, which together with the tmpfs
patches I just posted, get that combination working better.
fs/stack.c |6 +++
fs/unionfs/inode.c | 83 +--
fs/unionfs/mmap.c |3 -
3 files changed, 47 insertions(+), 45
Intensive swapoff testing shows shmem_unuse spinning on an entry in
shmem_swaplist pointing to itself: how does that come about? Days pass...
First guess is this: shmem_delete_inode tests list_empty without taking the
global mutex (so the swapping case doesn't slow down the common case); but
Nick has observed that shmem.c still uses GFP_ATOMIC when adding to page
cache or swap cache, without any radix tree preload: so tending to deplete
emergency reserves of memory.
GFP_ATOMIC remains appropriate in shmem_writepage's add_to_swap_cache:
it's being called under memory pressure, so must
There are a couple of reasons (patches follow) why it would be good to open
a window for sleep in shmem_unuse_inode, between its search for a matching
swap entry, and its handling of the entry found.
shmem_unuse_inode must then use igrab to hold the inode against deletion in
that window, and its
shmem_unuse is at present an unbroken search through every swap vector page
of every tmpfs file which might be swapped, all under shmem_swaplist_lock.
This dates from long ago, when the caller held mmlist_lock over it all too:
long gone, but there's never been much pressure for preemptible
tmpfs has long allowed for a fresh filepage to be created in pagecache,
just before shmem_getpage gets the chance to match it up with the swappage
which already belongs to that offset. But unionfs_writepage now does a
find_or_create_page, divorced from shmem_getpage, which leaves conflicting
tmpfs is expected to limit the memory used (unless mounted with nr_blocks=0
or size=0). But if a stacked filesystem such as unionfs gets pages from a
sparse tmpfs file by reading holes, and then writes to them, it can easily
exceed any such limit at present.
So suppress the SGP_READ "don't
Oops, try that again with Jens' new address.
Phillip Susi wrote:
Thomas Meyer wrote:
Hi,
is somebody actually working on this bug?
http://bugzilla.kernel.org/show_bug.cgi?id=9370
I don't want to be impolite, but it's now more than a month since the
bug was opened.
The bug still exists in
move_to_swap_cache and move_from_swap_cache functions (which swizzle a
page between tmpfs page cache and swap cache, to avoid page copying) are
only used by shmem.c; and our subsequent fix for unionfs needs different
treatments in the two instances of move_from_swap_cache. Move them from
add_to_swap_cache doesn't amount to much: merge it into its sole caller
read_swap_cache_async. But we'll be needing to call __add_to_swap_cache
from shmem.c, so promote it to the new add_to_swap_cache. Both were
static, so there's no interface confusion to worry about.
And lose that
"peerchen" <[EMAIL PROTECTED]> writes:
> According to the HyperTransport spec, 'En' indicate if the MSI Mapping is
> active.
> Set the 'En' bit when setup pci and add the quirk for some nvidia devices.
>
> The patch base on kernel 2.6.24-rc5
Ok. This is starting to look good.
> Signed-off-by:
Both unionfs and memcgroups pose challenges to tmpfs and shmem. To help
fix, it's best to move the swap swizzling functions from swap_state.c
to shmem.c. As a preliminary to that, move swap stats updating down
into __add_to_swap_cache, which will remain internal to swap_state.c.
Well, actually,
Neither unionfs nor memcgroups are working correctly with tmpfs and shmem.
If either or both are to go forward to 2.6.25, we shall need these patches
(against 2.6.24-rc5-mm1, but not dependent on unionfs or memcgroups) to go
in ahead. A small set for unionfs and a smaller set for memcgroups
* Roland McGrath <[EMAIL PROTECTED]> wrote:
> IOPL_MASK went away and kvm/vmx.c doesn't compile.
thanks, applied.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Tue, 18 Dec 2007, Chuck Ebbert wrote:
> On 12/18/2007 04:09 PM, Linus Torvalds wrote:
> >
> > I wonder what the heck is the point of that pnp entry. Just for fun, can
> > you try to just disable CONFIG_PNP, and see if it all works then?
>
> pnpacpi=off should work.
>
> PnP is also trying
Actual code let compiler generates idiv instruction on x86.
Using a right shift is OK here and readable as well.
Before patch
10: 57 push %edi
11: 56 push %esi
12: 89 d6 mov%edx,%esi
14: 53
On Tue, Dec 18, 2007 at 01:09:15PM -0800, Linus Torvalds wrote:
> However, I wonder about that
>
> e000-efff : pnp 00:0b
>
> thing. I actually suspect that that whole allocation is literally *meant*
> for that 256MB graphics aperture, but the kernel explicitly avoids it
> because
Thomas Meyer wrote:
Hi,
is somebody actually working on this bug?
http://bugzilla.kernel.org/show_bug.cgi?id=9370
I don't want to be impolite, but it's now more than a month since the
bug was opened.
The bug still exists in v2.6.24-rc5-43-gda8cadb:
Have you tried simply removing the line
On Wed, 19 Dec 2007, Ivan Kokshaysky wrote:
>
> Doh. Let's fix the kernel first...
>
> Does this make any difference? (the patch is self explaining ;-)
Heh, indeed. Good catch - that
Prefetchable memory behind bridge: -0fff
on device 00:01.0 does look
On 12/18/2007 04:09 PM, Linus Torvalds wrote:
>
> I wonder what the heck is the point of that pnp entry. Just for fun, can
> you try to just disable CONFIG_PNP, and see if it all works then?
>
pnpacpi=off should work.
PnP is also trying (and failing) to reserve all physical memory.
--
To
IOPL_MASK went away and kvm/vmx.c doesn't compile.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index bb56ae3..000 100644
--- a/drivers/kvm/vmx.c
+++ b/drivers/kvm/vmx.c
@@ -524,7 +524,7 @@ static unsigned long vmx_get_rflags(stru
Johannes Weiner wrote:
Hi,
Stephen Clark <[EMAIL PROTECTED]> writes:
userspace
Please supply the full dmesg output on the non-working kernel the
corresponding .config (or /proc/config.gz).
Added Dave to CC.
Hannes
Duh - I rebooted into the new kernel and no longer see
Alon Bar-Lev wrote:
Hello,
I am trying to build a basic initramfs image into the kernel, using
the CONFIG_INITRAMFS_SOURCE. The required result is a single image
loaded into a target containing usermode application (busybox).
I use cross compile mipsel-unknown-linux-uclibc in order to build
On Tuesday 18 December 2007, Glauber de Oliveira Costa wrote:
> On Dec 18, 2007 6:54 PM, Frans Pop <[EMAIL PROTECTED]> wrote:
> > Glauber de Oliveira Costa wrote:
> > > What's left in processor_32.h and processor_64.h cannot be cleanly
> > > integrated. However, it's just a couple of definitions.
On Tue, Dec 18, 2007 at 12:22:34PM -0800, Richard Henderson wrote:
> On Tue, Dec 18, 2007 at 10:21:50AM -0800, Linus Torvalds wrote:
> > ... and that would be an X server issue!).
>
> Of course, fixing the X server to *handle* 64-bit BARs is the correct
> solution. I've no idea how involved that
Some 'extern struct seq_operations' are wrongly defined in fs/proc/proc_misc.c
(they miss a const qualifier)
In order to fix this correctly, move the "extern ... " declaration from .c
file to an appropriate include file, as advised by checkpatch.pl
Note : "extern struct seq_operations
On Tue, Dec 18, 2007 at 10:21:50AM -0800, Linus Torvalds wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=425794#c0
>
> That bugzilla entry doesn't even have a dmesg output or anything like
> that. I'd really like to see what the
I've added dmesg, /proc/iomem, and lspci -v output to that
On Dec 18 2007 21:37, Eric Dumazet wrote:
>
> If turning off tcp_sack makes the problem go away, why dont you
> turn it off all the time ?
>
That would just be workaround. I welcome the efforts to track this;
not all users have the time to do so.
Disabling tcp_sack also disabled it kernel-wide,
V2 -> V3:
+ rebase to 23-mm1 atop RvR's split lru series
+ fix page flags macros for *PageMlocked() when not configured.
+ ensure lru_add_drain_all() runs on all cpus when NORECLIM_MLOCK
configured. Was just for NUMA.
V1 -> V2:
+ moved this patch [and related patches] up to right after
V2 -> V3:
+ rebase to 23-mm1 atop RvR's split lru series
+ fix definitions of NR_MLOCK to fix build errors when not configured.
V1 -> V2:
+ new in V2 -- pulled in & reworked from Nick's previous series
From: Nick Piggin <[EMAIL PROTECTED]>
To: Linux Memory Management <[EMAIL PROTECTED]>
Split the LRU lists in two, one set for pages that are backed by
real file systems ("file") and one for pages that are backed by
memory and swap ("anon"). The latter includes tmpfs.
Eventually mlocked pages will be taken off the LRUs alltogether.
A patch for that already exists and just needs to
V1 -> V3:
+ rebase to 23-mm1 atop RvR's split LRU series
+ define NR_NORECLAIM and LRU_NORECLAIM to avoid errors when not
configured.
V1 -> V2:
+ handle review comments -- various typos and errors.
+ extract "putback_all_noreclaim_pages()" into a separate patch
and rework as
V1 -> V2 [lts]:
+ fix botched merge -- add back "get_page_unless_zero()"
From: Nick Piggin <[EMAIL PROTECTED]>
To: Linux Memory Management <[EMAIL PROTECTED]>
Subject: [patch 1/4] mm: move and rework isolate_lru_page
Date: Mon, 12 Mar 2007 07:38:44 +0100 (CET)
isolate_lru_page logically
V1 -> V2 [lts]:
+ Remove extraneous __dec_zone_state(zone, NR_ACTIVE) pointed
out by Mel G.
>From [EMAIL PROTECTED] Wed Aug 29 11:39:51 2007
Currently we are defining explicit variables for the inactive
and active list. An indexed array can be more generic and avoid
repeating similar code in
I have seen soft cpu lockups in page_referenced_file() due to
contention on i_mmap_lock() for different pages. Making the
i_mmap_lock a reader/writer lock should increase parallelism
in vmscan for file back pages mapped into many address spaces.
Read lock the i_mmap_lock for all usage except:
V2 -> V3:
+ rebase to 23-mm1 atop RvR's split LRU series [no changes]
V1 -> V2:
+ add ramfs pages to this class of non-reclaimable pages by
marking ramfs address_space [mapping] as non-reclaimble.
Christoph Lameter pointed out that ram disk pages also clutter the
LRU lists. When vmscan
V2 -> V3:
+ rebase to 23-mm1 atop RvR's split LRU series
New in V2
This patch adds a function to scan individual or all zones' noreclaim
lists and move any pages that have become reclaimable onto the respective
zone's inactive list, where shrink_inactive_list() will deal with them.
This
V2 -> V3:
+ rebase to 23-mm1 atop RvR's split lru series [no changes]
V1 -> V2:
+ modified mmap.c:mmap_region() to return error if mlock_vma_pages_range()
does. This can only occur if the vma gets removed/changed while
we're switching mmap_sem lock modes. Most callers don't care, but
Swapin_readahead can read in a lot of data that the processes in
memory never need. Adding swap cache pages to the inactive list
prevents them from putting too much pressure on the working set.
This has the potential to help the programs that are already in
memory, but it could also be a
V2 -> V3:
+ rebase to 23-mm1 atop RvR's split LRU series.
+ Use scan_mapping_noreclaim_page() on unlock. See below.
V1 -> V2:
+ modify to use reworked 'scan_all_zones_noreclaim_pages()'
See 'TODO' below - still pending.
While working with Nick Piggin's mlock patches, I noticed that
shmem
Update the split anon & file LRU code to deal with the recent
memory controller changes.
Signed-off-by: Rik van Riel <[EMAIL PROTECTED]>
Index: linux-2.6.24-rc3-mm2/include/linux/memcontrol.h
===
---
V2 -> V3:
+ rebase to 23-mm1 atop RvR's split LRU series
V1 -> V2:
no changes
Report non-reclaimable pages per zone and system wide.
Note: may want to track/report some specific reasons for
nonreclaimability for deciding when to splice the noreclaim
lists back to the normal lru. That
We avoid evicting and scanning anonymous pages for the most part, but
under some workloads we can end up with most of memory filled with
anonymous pages. At that point, we suddenly need to clear the referenced
bits on all of memory, which can take ages on very large memory systems.
We can reduce
V2 -> V3:
+ rebase to 23-mm1 atop RvR's split lru series [no change]
+ fix function return types [void -> int] to fix build when
not configured.
New in V2.
We need to hold the mmap_sem for write to initiatate mlock()/munlock()
because we may need to merge/split vmas. However, this can lead to
Debug whether we end up classifying the wrong pages as
filesystem backed. This has not triggered in stress
tests on my system, but who knows...
Signed-off-by: Rik van Riel <[EMAIL PROTECTED]>
Index: linux-2.6.24-rc3-mm2/include/linux/mm_inline.h
Define page_file_cache() function to answer the question:
is page backed by a file?
Originally part of Rik van Riel's split-lru patch. Extracted
to make available for other, independent reclaim patches.
Moved inline function to linux/mm_inline.h where it will
be needed by subsequent
+ lts' convert anon_vma list lock to reader/write lock patch
+ Nick Piggin's move and rework isolate_lru_page() patch
Free swap cache entries when swapping in pages if vm_swap_full()
[swap space > 1/2 used?]. Uses new pagevec to reduce pressure
on locks.
Signed-off-by: Rik van Riel <[EMAIL
Make the anon_vma list lock a read/write lock. Heaviest use of this
lock is in the page_referenced()/try_to_unmap() calls from vmscan
[shrink_page_list()]. These functions can use a read lock to allow
some parallelism for different cpus trying to reclaim pages mapped
via the same set of vmas.
On large memory systems, the VM can spend way too much time scanning
through pages that it cannot (or should not) evict from memory. Not
only does it use up CPU time, but it also provokes lock contention
and can leave large systems under memory presure in a catatonic state.
This patch series
On Tue, 18 Dec 2007, Richard Henderson wrote:
>
> I've added dmesg, /proc/iomem, and lspci -v output to that bug.
>
> Basically, we have
>
> c000-cfff : free
> ddf0-dfef : PCI Bus #04
> e000-efff : pnp 00:0b
> f000-fedf : less than 256MB
> However, your older patch series looks like you want this behavior also
> in areas which are mapped by dma_map_sg(), do you?. Still, adding two
> functions of the kind like above, if necessary, might still be
> preferable to changing the call parameters of existing functions or to
>
* Glauber de Oliveira Costa <[EMAIL PROTECTED]> wrote:
> On Dec 18, 2007 6:54 PM, Frans Pop <[EMAIL PROTECTED]> wrote:
> > Glauber de Oliveira Costa wrote:
> > > What's left in processor_32.h and processor_64.h cannot be cleanly
> > > integrated. However, it's just a couple of definitions. They
On Dec 18, 2007 6:54 PM, Frans Pop <[EMAIL PROTECTED]> wrote:
> Glauber de Oliveira Costa wrote:
> > What's left in processor_32.h and processor_64.h cannot be cleanly
> > integrated. However, it's just a couple of definitions. They are moved
> > to processor.h around ifdefs, and the original
[EMAIL PROTECTED] wrote:
> Reorderings are possible on reads and
> writes. Things get synced up by either an interrupt or a write to
> a memory region with a "barrier attribute". Memory allocated with
> dma_alloc_coherent() gets the barrier attribute. The idea here is
> to allow memory allocated
Thanks to Josef Bacik for finding these.
A couple of ecryptfs error paths don't properly unlock things they locked.
Signed-off-by: Eric Sandeen <[EMAIL PROTECTED]>
Cc: Josef Bacik <[EMAIL PROTECTED]>
---
Index: linux-2.6.24-rc3/fs/ecryptfs/crypto.c
Andrew,
Thanks your your comments, I'm currently preparing/testing a revised patch
based on your suggestions, which I will post later this week.
A couple of comments inline.
Steve
I wouldn't bother with EXPERIMENTAL personally. It seems a farily
pointless thing.
OK, I copied one of the
101 - 200 of 816 matches
Mail list logo
