> Thanks, Andi! I think it'd very useful change.
Reminds me this is something that should be actually flagged
in checkpatch.pl too
Andy, it would be good if checkpatch.pl complained about .ioctl =
as opposed to .unlocked_ioctl = ...
Also perhaps if a whole new file_operations with a ioctl is
On Tue, 2008-01-08 at 20:08 +0100, Miklos Szeredi wrote:
>
> The logic behind EPERM, is that this failure is only for unprivileged
> callers. ENOMEM is too specifically about OOM. It could be changed
> to ENOSPC, ENFILE, EMFILE, or it could remain EPERM. What do others
> think?
Since you're
Hi!
>
> > > a quick feature request: could you please make the wake-on-RTC
> > > capability generic and add a CONFIG_DEBUG_SUSPEND_ON_RAM=y config
> > > option (disabled by default) that does a short 1-second
> > > suspend-to-RAM sequence upon bootup? That way we could test s2ram
> > >
On Tue, 08 Jan 2008 13:44:54 -0500
"David P. Reed" <[EMAIL PROTECTED]> wrote:
> Ondrej Zary wrote:
> > On Tuesday 08 January 2008 18:24:02 David P. Reed wrote:
> >
> >> Windows these days does delays with timing loops or the
> >> scheduler. It doesn't use a "port". Also, Windows XP only
> >>
> As well you should. I am honestly curious (for my own satisfaction) as
> to what the natsemi docs say the delay code should do (can't imagine
> they say "use io port 80 because it is unused"). I don't have any
They say you must allow 4 bus clocks for the address decode. They don't
deal
On Mon, Jan 07, 2008 at 06:11:42PM -0800, [EMAIL PROTECTED] wrote:
>
> This patchset simplifies the code that arches need to maintain to support
> per cpu functionality. Most of the code is moved into arch independent
> code. Only a minimal set of definitions is kept for each arch.
>
> The patch
On Tue, 8 Jan 2008, Ingo Molnar wrote:
> i had the patch below for v2, it's still needed (because i didnt apply
> the s390/etc. bits), right?
Well the patch really should go through mm because it is a change that
covers multiple arches. I think testing with this is fine. I think Mike
has
Hi all,
the following 5 patches fix 227 errors and 2 warnings
reported by checkpatch.pl
I hope they don't introduce problems in the process and
that they can be applied.
I know there is no agreement on the list about whether these
patches should be posted/accepted or not so I'm just resending
Fix one error reported by checkpatch,
it now reports:
total: 0 errors, 0 warnings, 42 lines checked
Signed-off-by: Paolo Ciarrocchi <[EMAIL PROTECTED]>
---
arch/x86/ia32/audit.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/ia32/audit.c
Fix a few coding style violations (37 errors).
Checkpatch now reports:
total: 2 errors, 1 warnings, 183 lines checked
Signed-off-by: Paolo Ciarrocchi <[EMAIL PROTECTED]>
---
arch/x86/ia32/fpu32.c | 68
1 files changed, 34 insertions(+), 34
Fix plenty of coding style errors
Checkpatch now reports:
total: 2 errors, 18 warnings, 526 lines checked
Signed-off-by: Paolo Ciarrocchi <[EMAIL PROTECTED]>
---
arch/x86/ia32/ia32_aout.c | 100 ++---
1 files changed, 49 insertions(+), 51 deletions(-)
Fix 39 Codying Style errors reported by checkpatch
It now reports:
total: 2 errors, 5 warnings, 285 lines checked
Signed-off-by: Paolo Ciarrocchi <[EMAIL PROTECTED]>
---
arch/x86/ia32/ia32_binfmt.c | 70 +-
1 files changed, 35 insertions(+), 35
fix plenty of codying style errors
Checkpatch now reports:
total: 3 errors, 9 warnings, 617 lines checked
Signed-off-by: Paolo Ciarrocchi <[EMAIL PROTECTED]>
---
arch/x86/ia32/ia32_signal.c | 192 +-
1 files changed, 96 insertions(+), 96 deletions(-)
On Tue, 8 Jan 2008, Arjan van de Ven wrote:
>
> ok done; I had to fizzle a bit because some things aren't *exactly* a
> BUG() statement but I track them anyway (things like the "sleeping in
> invalid context" check), so I had to somewhat arbitrarily assign
> categories for those. I might
Linus Torvalds wrote:
On Tue, 8 Jan 2008, Arjan van de Ven wrote:
the database has the information so it's just a matter of slightly different
php code ;)
Before I do that... do you want the BUG's separate, part of the warnings or
part of the oopses?
(I rather make this change once ;)
I'd
> On Tue, 2008-01-08 at 12:35 +0100, Miklos Szeredi wrote:
> > +static int reserve_user_mount(void)
> > +{
> > + int err = 0;
> > +
> > + spin_lock(_lock);
> > + if (nr_user_mounts >= max_user_mounts && !capable(CAP_SYS_ADMIN))
> > + err = -EPERM;
> > + else
>
On Tuesday 08 January 2008 19:51:41 Bodo Eggert wrote:
> On Tue, 8 Jan 2008, Ondrej Zary wrote:
> > On Tuesday 08 January 2008 18:24:02 David P. Reed wrote:
> > > Windows these days does delays with timing loops or the scheduler. It
> > > doesn't use a "port". Also, Windows XP only supports
Alan Cox wrote:
The natsemi docs here say otherwise. I trust them not you.
As well you should. I am honestly curious (for my own satisfaction) as
to what the natsemi docs say the delay code should do (can't imagine
they say "use io port 80 because it is unused"). I don't have any
copies
> On Tue, 2008-01-08 at 12:35 +0100, Miklos Szeredi wrote:
> > plain text document attachment
> > (unprivileged-mounts-account-user-mounts.patch)
> > From: Miklos Szeredi <[EMAIL PROTECTED]>
> >
> > Add sysctl variables for accounting and limiting the number of user
> > mounts.
> ...
> > +int
Hello,
the commit "x86: optimize page faults like all other achitectures and
kill notifier cruft" by Christoph Hellwig removed the page fault
notifiers (e.g. register_page_fault_notifier()) completely in 2.6.24.
Mmio-trace [1] is using them for tracking memory mapped IO, and also
other people
Move the initialzation in __svc_create_thread that happens prior to
thread creation to a new function. Export the function to allow
services to have better control over the svc_rqst structs.
Also rearrange the rqstp initialization to prevent NULL pointer
dereferences in svc_exit_thread in case
Needed since the plan is to not have a svc_create_thread helper and to
have current users of that function just call kthread_run directly.
Signed-off-by: Jeff Layton <[EMAIL PROTECTED]>
---
net/sunrpc/svcsock.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git
lockd makes itself freezable, but never calls try_to_freeze(). Have it
call try_to_freeze() within the main loop.
Signed-off-by: Jeff Layton <[EMAIL PROTECTED]>
---
fs/lockd/svc.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/fs/lockd/svc.c b/fs/lockd/svc.c
index
...and only have lockd exit when the last reference is dropped.
The problem is this:
When a lock that a client is blocking on comes free, lockd does this in
nlmsvc_grant_blocked():
nlm_async_call(block->b_call, NLMPROC_GRANTED_MSG, _grant_ops);
the callback from this call is
lockd_start_done is a global var that can be reused if lockd is
restarted, but it's never reinitialized. On all but the first use,
wait_for_completion isn't actually waiting on it since it has
already completed once.
Signed-off-by: Jeff Layton <[EMAIL PROTECTED]>
---
fs/lockd/svc.c |1 +
1
This is the sixth patchset to fix the use-after-free problem in lockd
which we originally discussed back in October. The main problem is
detailed in the last patch of the series. Along the way, Christoph
Hellwig mentioned that it would be advantageous to convert lockd to use
the kthread API. This
Have lockd_up start lockd using kthread_run. With this change,
lockd_down now blocks until lockd actually exits, so there's no longer
need for the waitqueue code at the end of lockd_down. This also means
that only one lockd can be running at a time which simplifies the code
within lockd's main
On Tuesday 08 January 2008 14:21:57 Pierre Ossman wrote:
> Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > The on-chip Blackfin MMC/SD/SDIO host controller has the ability to do
> > 1-bit MMC, 1-bit/4-bit SD, and 1-bit/4-bit SDIO. Thus the current
> > convention of MMC_CAP_4_BIT_DATA meaning "your
On Sun, 6 Jan 2008 20:02:46 -0800
"raki john" <[EMAIL PROTECTED]> wrote:
>
> Can I replace drivers/mmc directory in 2.6.22.1 with drivers/mmc
> directory in 2.6.23.1. Does this cause any issues. Is there any code
> in drivers/mmc in 2.6.23.1 which depends on other features in kernel
>
On Mon, 7 Jan 2008 15:31:32 -0800
"raki john" <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> Please CC me on responses.
>
> I am working on a SD/MMC Host driver .
>
> I am getting kerenl oops after mmc_register_card () is called.
> i working on LINUX 2.6.22.1 kerenl.
>
> What might be the reason
Alan -
I dug up a DP83901A SNIC datasheet in a quick Google search, while that
wasn't the only such chip, it was one of them. I can forward the PDF
(the www.alldatasheet.com site dynamically creates the download URL), if
anyone wants it.
The relevant passage says, in regard to delaying
On Tue, 8 Jan 2008 20:58:04 +0100
"Paolo Ciarrocchi" <[EMAIL PROTECTED]> wrote:
> -static const struct file_operations rtc_fops = {
> +static long rtc_fioctl(struct file_operations rtc_fops)
> +{
> + lock_kernel();
> .owner = THIS_MODULE,
> .llseek = no_llseek,
>
On Tue, 2008-01-08 at 20:21 +0100, Sam Ravnborg wrote:
> But is discourage the creation of pure clean-up patches because it
> may have a disturbing effect on several other peoples work.
pure clean ups are _good_ patches , are they not?
Daniel
--
To unsubscribe from this list: send the line
On Tue, Jan 08, 2008 at 01:16:06PM -0700, Matthew Wilcox wrote:
> On Tue, Jan 08, 2008 at 09:03:13PM +0100, Paolo Ciarrocchi wrote:
> > Yes of course, I've been silly in didn't verify whether the file compile
> > but I would appreciate to know whether I'm on the right track or not.
>
> Well ...
solved... lpd was causing the hang.
- George
George Nychis wrote:
Hi all,
I noticed that all of a sudden my disk writes using VIM/EMACS are taking
3+ seconds for even just a single byte. So, I've used strace to narrow
it down to fsync.
The following log is an fsync opening up a new file
On Jan 8, 2008 9:00 PM, Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 08, 2008 at 08:58:04PM +0100, Paolo Ciarrocchi wrote:
> > -static const struct file_operations rtc_fops = {
> > +static long rtc_fioctl(struct file_operations rtc_fops)
> > +{
> > + lock_kernel();
> > .owner
> static void elf32_init(struct pt_regs *regs)
> {
> - struct task_struct *me = current;
> + struct task_struct *me = current;
> regs->rdi = 0;
> regs->rsi = 0;
> regs->rdx = 0;
> regs->rcx = 0;
> regs->rax = 0;
> - regs->rbx = 0;
> - regs->rbp =
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> These things *are* fairly rare (most bugs by _far_ are of the trivial
> stupid kind), but some of those things can stay around for a long
> time, and it can take months of different people reporting similar
> problems until somebody finally puts
On Jan 8, 2008 5:40 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> Here's a proposal for some useful code transformations the kernel janitors
> could do as opposed to running checkpatch.pl.
>
> Most ioctl handlers still running implicitely under the big kernel
> lock (BKL). But long term Linux is
> - if ((jiffies-error_time) > 5*HZ)
> - {
> - printk(KERN_WARNING
> + if ((jiffies-error_time) > 5*HZ) {
Should we expect second wave of this crap when you will suddenly realize
that it would be even nicer to write:
if (jiffies -
On Tue, Jan 08, 2008 at 08:58:04PM +0100, Paolo Ciarrocchi wrote:
> -static const struct file_operations rtc_fops = {
> +static long rtc_fioctl(struct file_operations rtc_fops)
> +{
> + lock_kernel();
> .owner = THIS_MODULE,
You should probably restrict yourself to files that
On Tue, 8 Jan 2008 20:32:33 +0100
Paolo Ciarrocchi <[EMAIL PROTECTED]> wrote:
> Fix plenty of coding style errors
Most of these kernel changes would probably get in the way of
real development, making patches reject that would otherwise
apply.
You did find one possible bug, though:
> @@ -467,9
> #define RELOAD_SEG(seg,mask) \
> { unsigned int cur; \
> - unsigned short pre; \
> - err |= __get_user(pre, >seg); \
> -
thanks, applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Jan 8, 2008 9:02 PM, Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> > static void elf32_init(struct pt_regs *regs)
> > {
> > - struct task_struct *me = current;
> > + struct task_struct *me = current;
> > regs->rdi = 0;
> > regs->rsi = 0;
> > regs->rdx = 0;
> >
On Tue, Jan 08, 2008 at 09:03:13PM +0100, Paolo Ciarrocchi wrote:
> On Jan 8, 2008 9:00 PM, Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> > On Tue, Jan 08, 2008 at 08:58:04PM +0100, Paolo Ciarrocchi wrote:
> > > -static const struct file_operations rtc_fops = {
> > > +static long rtc_fioctl(struct
On Tuesday 08 January 2008, Sam Ravnborg wrote:
> On Tue, Jan 08, 2008 at 08:50:33AM -0800, Daniel Walker wrote:
> >
> > On Tue, 2008-01-08 at 17:14 +0100, Andi Kleen wrote:
> >
> >
> > > +if ($file) {
> > > + print < > > +WARNING: Using --file mode. Please do not send patches to linux-kernel
>
>
> As your submission did not include an RFC I assume this is expected to be
> the final version.
I have another version coming that includes the changes requested by you
and others.
Thanks,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Steven Rostedt wrote:
> The following patch series brings to vanilla Linux a bit of the RT kernel
> trace facility. This incorporates the "-pg" profiling option of gcc
> that will call the "mcount" function for all functions called in
> the kernel.
>
> This patch series implements the code for
On Tue, 8 Jan 2008, Eric Dumazet wrote:
> Changli Gao a écrit :
> > Replace the epitem rbtree with a dynamic array to get the constant
> > insertion/deletion/modification time of the file descriptors. Reuse the
> > size argument of epoll_create, however the size must be smaller than the
> >
On Jan 8, 2008 9:42 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > I grepped and tried to do what you suggested.
>
> First a quick question: how would you rate your C knowledge? Did you
> ever write a program yourself?
Yes I did but I probably beeing inactive for too much time,
I need to back
On Tue, Jan 08, 2008 at 11:44:34AM +0300, Alexey Dobriyan wrote:
> [PATCH -mm 2/4] hifn_795x: fixup container_of() usage
>
> Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
Patch applied. Thanks.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
On Tue, 8 Jan 2008 14:40:49 -0500
Mike Frysinger <[EMAIL PROTECTED]> wrote:
>
> i dont understand what's confusing. the Blackfin on chip host controller
> only
> supports 1-bit MMC, but it supports 4-bit SD/SDIO. this is a fact. while it
> may be a stupid decision, it is what it is, and i
On Tue, Jan 08, 2008 at 03:04:39PM -0500, Rik van Riel wrote:
> On Tue, 8 Jan 2008 20:32:33 +0100
> Paolo Ciarrocchi <[EMAIL PROTECTED]> wrote:
>
> > Fix plenty of coding style errors
>
> Most of these kernel changes would probably get in the way of
> real development, making patches reject that
Theodore Tso <[EMAIL PROTECTED]> writes:
>
> Now, there are good reasons for doing periodic checks every N mounts
> and after M months. And it has to do with PC class hardware. (Ted's
> aphorism: "PC class hardware is cr*p").
If these reasons are good ones (some skepticism here) then the
On Tue, 8 Jan 2008, Miklos Szeredi wrote:
> > On Tue, 2008-01-08 at 12:35 +0100, Miklos Szeredi wrote:
> > > +static int reserve_user_mount(void)
> > > +{
> > > + int err = 0;
> > > +
> > > + spin_lock(_lock);
> > > + if (nr_user_mounts >= max_user_mounts &&
On Jan 8, 2008 9:21 PM, Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 08, 2008 at 01:16:06PM -0700, Matthew Wilcox wrote:
> > On Tue, Jan 08, 2008 at 09:03:13PM +0100, Paolo Ciarrocchi wrote:
> > > Yes of course, I've been silly in didn't verify whether the file compile
> > > but I would
Linus, please pull from
master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus
This tree is also available from kernel.org mirrors at:
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
for-linus
This will get a few one-line fixes: change a
Sorry for the late reply.
comments below...
On Fri, Jan 04, 2008 at 09:53:38AM +0800, Zhenyu Wang wrote:
> On 2007.12.19 13:26:08 +, Zhenyu Wang wrote:
> >
> > [agp-mm] [intel_iommu] explicit export current graphics dmar status
> >
> > To make it possbile to tell other modules about curent
> I grepped and tried to do what you suggested.
First a quick question: how would you rate your C knowledge? Did you
ever write a program yourself?
My proposal assumes that you have at least basic C knowledge.
> The first file that git grep reported was:
> arch/arm/common/rtctime.c:static
On Tue, Jan 08, 2008 at 09:06:38PM +0200, Pekka Paalanen wrote:
> - Is there anything coming to replace register_page_fault_notifier()?
no.
> - Has someone found another way to accomplish the same without patching
> the kernel?
no.
> - Should I start writing a patch to bring back the
Christer Weinigel wrote:
There is no need to use io writes to supposedly/theoretically "unused
ports" to make drivers work on any bus.
ISA included! You can, for example, wait for an ISA bus serial
adapter to put out its next character by looping reading the port
that has the output buffer
This patchset simplifies the code that arches need to maintain to support
per cpu functionality. Most of the code is moved into arch independent
code. Only a minimal set of definitions is kept for each arch.
The patch also unifies the x86 arch so that there is only a single
asm-x86/percpu.h
x86_64 provides an optimized way to determine the local per cpu area
offset through the pda and determines the base by accessing a remote
pda.
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Christoph Lameter
The use of the __GENERIC_PERCPU is a bit problematic since arches
may want to run their own percpu setup while using the generic
percpu definitions. Replace it through a kconfig variable.
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: Sam Ravnborg <[EMAIL PROTECTED]>
x86_32 only provides a special way to obtain the local per cpu area offset
via x86_read_percpu. Otherwise it can fully use the generic handling.
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis
On Tuesday 08 January 2008 21:51:53 Andi Kleen wrote:
> Theodore Tso <[EMAIL PROTECTED]> writes:
> > Now, there are good reasons for doing periodic checks every N mounts
> > and after M months. And it has to do with PC class hardware. (Ted's
> > aphorism: "PC class hardware is cr*p").
>
> If
Ananth N Mavinakayanahalli <[EMAIL PROTECTED]> writes:
> kernel/kprobes.c|2
> kernel/test_kprobes.c | 216
>
Can you put this somewhere else please? I know there are already some
test files in kernel/* but imho they all belong
Add the ability to use generic/percpu even if the arch needs to override
several aspects of its operations. This will enable the use of generic
percpu.h for all arches.
An arch may define:
__per_cpu_offsetDo not use the generic pointer array. Arch must
define
The arch definitions are all the same. So move them into linux/percpu.h.
We cannot move DECLARE_PER_CPU since some include files just include
asm/percpu.h to avoid include recursion problems.
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Christoph
Change s390 percpu.h to use asm-generic/percpu.h
Cc: [EMAIL PROTECTED]
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
V2->V3:
On Thu, 29 Nov 2007, Martin Schwidefsky wrote:
> On Wed, 2007-11-28 at 13:09 -0800, Christoph Lameter wrote:
>
ia64 has a special processor specific mapping that can be used to locate the
offset for the current per cpu area.
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
V1->V2:
- Merge fixes
- Remove
Sparc64 has a way of providing the base address for the per cpu area of the
currently executing processor in a global register.
Sparc64 also provides a way to calculate the address of a per cpu area
from a base address instead of performing an array lookup.
Cc: David Miller <[EMAIL PROTECTED]>
Powerpc has a way to determine the address of the per cpu area of the
currently executing processor via the paca and the array of per cpu
offsets is avoided by looking up the per cpu area from the remote
paca's (copying x86_64).
Cc: Paul Mackerras <[EMAIL PROTECTED]>
Signed-off-by: Christoph
Form a single percpu.h from percpu_32.h and percpu_64.h. Both are now pretty
small so this is simply adding them together.
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL
During an AIM7 run on a 16GB system, fork started failing around
32000 threads, despite the system having plenty of free swap and
15GB of pageable memory.
If normal pageout does not result in contiguous free pages for
kernel stacks, fall back to lumpy reclaim instead of failing fork
or doing
The access ratio based scan rate determination in get_scan_ratio
works ok in most situations, but needs to be corrected in some
corner cases:
- if we run out of swap space, do not bother scanning the anon LRUs
- if we have already freed all of the page cache, we need to scan
the anon LRUs
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
+ 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
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
V2 -> V3:
+ rebase to 23-mm1 atop RvR's split lru series.
V1 -> V2:
+ no changes
Optional part of "noreclaim infrastructure"
In the fault paths that install new anonymous pages, check whether
the page is reclaimable or not using lru_cache_add_active_or_noreclaim().
If the page is reclaimable,
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
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
V3 -> V4:
+ drivers/block/rd.c was replaced by brd.c in 24-rc4-mm1.
Update patch to add brd_open() to mark mapping as nonreclaimable
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
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
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
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
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
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
+ 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
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.
Against 2.6.24-rc6-mm1
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
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]>
On Tue, Jan 08, 2008 at 12:19:44PM -0800, Daniel Walker wrote:
> > But is discourage the creation of pure clean-up patches because it
> > may have a disturbing effect on several other peoples work.
>
> pure clean ups are _good_ patches , are they not?
>
Not necessarily. Whether or not it is
On Dec 22, 2007 2:06 AM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> Oh boy. Do we really want to add all this stuff to JBD just for
> drop_caches which is a silly root-only broken-in-22-other-ways thing?
>
> Michael, might your convert-inode-lists-to-tree patches eliminate the need
> for taking
On Fri, Dec 21, 2007 at 08:05:30PM -0600, Trevor Highland wrote:
> eCryptfs: Load each file decryption key only once
>
> There is no need to keep re-setting the same key for any given
> eCryptfs inode. This patch optimizes the use of the crypto API and
> helps performance a bit.
There is no
On Dec 22, 2007 2:06 AM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Mon, 17 Dec 2007 12:13:22 + richard <[EMAIL PROTECTED]> wrote:
> Michael, might your convert-inode-lists-to-tree patches eliminate the need
> for taking inode_lock in drop_pagecache_sb()? Probably not, as it uses an
>
On Wednesday 09 January 2008 03:18:46 Ingo Molnar wrote:
> * DM <[EMAIL PROTECTED]> wrote:
> > On Jan 8, 2008 3:26 PM, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > > > Why use sprintf? If a module name contains the % character we could
> > > > overflow the buffer. Or is module-unloading
Andi Kleen wrote:
> Theodore Tso <[EMAIL PROTECTED]> writes:
> > Now, there are good reasons for doing periodic checks every N mounts
> > and after M months. And it has to do with PC class hardware. (Ted's
> > aphorism: "PC class hardware is cr*p").
>
> If these reasons are good ones (some
901 - 1000 of 1301 matches
Mail list logo
