On Fri, 2005-04-08 at 15:32 +0200, Franck Bui-Huu wrote:
> As I described in my previous email, bootmem.c does improper
> pfn convertions into phys addr. This simple patch fixes that.
...
> - bdata->node_bootmem_map = phys_to_virt(mapstart << PAGE_SHIFT);
> - bdata->node_boot_start = (s
oved
their arch-specific DISCONTIG prompt in favor of the mm/Kconfig one.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
arch/i386/Kconfig |0
memhotplug-dave/mm/Kconfig | 21 +
2 files changed, 17 insertions(+), 4 deletions(-)
diff -puN mm/Kconf
This used to be used to disable FLATMEM selection, but I decided
to change it to be done generically when DISCONTIG is enabled.
The option is unused, so this kills it.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
memhotplug-dave/./arch/mips/Kconfig |4
memhotplug-dave/
This gives DISCONTIGMEM a bit more help text to explain
what it does, not just when to choose it.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
memhotplug-dave/mm/Kconfig | 10 ++
1 files changed, 10 insertions(+)
diff -puN mm/Kconfig~A2-mm-Kconfig-DISCONTIG-help-t
On Mon, 2005-07-11 at 10:42 +0100, Paul Sladen wrote:
> The sensor gives us two 10-bit AD values (corresponding to 0..1 volts on the
> ADI chip), temperature (Celsius) and three status bits indicating:
>
> * lid open/closed
Which bit did you find this in? I haven't tried with the lid closed.
On Mon, 2005-07-11 at 15:26 +0100, Alan Cox wrote:
> On Llu, 2005-07-11 at 10:42, Paul Sladen wrote:
> > theta = (N - 512) * 0.5
> >
> > provides a surprisingly good approximation for pitch/roll values in degrees
> > in the range (-90..+90) so I think the sensor can do ~= +/-2.5G .
> >
> > ht
On Mon, 2005-07-11 at 22:09 +0200, Daniel Willmann wrote:
> I have implemented an absolute input driver (aka joystick) on the
> basis of Dave's 0.02 version of the driver. I attached the diff to this
> mail or just get it from:
> http://thebe.orbit.homelinux.net/~alphaone/ibm_hdaps_joystick.tar.gz
On Thu, 2005-07-14 at 13:28 -0700, Nishanth Aravamudan wrote:
> +static inline u64 jiffies_to_nsecs(const unsigned long j)
> +{
> +#if HZ <= NSEC_PER_SEC && !(NSEC_PER_SEC % HZ)
> + return (NSEC_PER_SEC / HZ) * (u64)j;
> +#elif HZ > NSEC_PER_SEC && !(HZ % NSEC_PER_SEC)
> + return ((u64)j +
On Sun, 2005-08-07 at 16:20 -0700, Martin J. Bligh wrote:
> Starting on the work to merge xen cleanly as a subarch.
> Introduce make_pages_readonly and make_pages_writable where appropriate
> for Xen, defined as a no-op on other subarches. Same for
> add_context_to_unpinned and del_context_from_
On Wed, 2005-08-10 at 18:27 +0100, Mel Gorman wrote:
> I later linearly scan the mem_map looking for pages that can be freed up
> (usually LRU pages). I was expecting any page with PG_inode set to have a
> page->mapping but not all of them do. It is the pages without a ->mapping
> that are confusin
This splits up sparse_index_alloc() into two pieces. This is needed
because we'll allocate the memory for the second level in a different
place from where we actually consume it to keep the allocation from
happening underneath a lock
Signed-off-by: Dave Hansen <[EMAIL P
This applies to 2.6.13-rc5-mm1 and replaces the existing
sparsemem-extreme.patch
From: Bob Picco <[EMAIL PROTECTED]>
With cleanups from Dave Hansen <[EMAIL PROTECTED]>
SPARSEMEM_EXTREME makes mem_section a one dimensional array of
pointers to mem_sections. This two level layo
lse for a memory area that's being removed. The lock is
only required when doing pfn_valid() operations on memory which the
user does not already have a reference on the page, such as in
show_mem().
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
memhotplug-dave/arch/a
We'll fix it up properly once
it calms down.
Signed-off-by: Matt Tolentino <[EMAIL PROTECTED]>
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
memhotplug-dave/drivers/base/Makefile |1
memhotplug-dave/drivers/base/init.c|2
memhotplug-dave
.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
memhotplug-dave/mm/memory_hotplug.c | 43
memhotplug-dave/mm/sparse.c | 74 +---
2 files changed, 70 insertions(+), 47 deletions(-)
diff -puN mm/sparse.
Add an if() to the wait-table init code to allow runtime
allocations to call kmalloc() instead of using the
bootmem allocator
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
./arch/sparc64/kernel/dtlb_base.S |0
memhotplug-dave/mm/page_alloc.c | 10 +++---
2 files chan
Here is a set of ppc64 specific patches that at least allow
compilation/booting with the following configurations:
FLATMEM
SPARSEMEN
SPARSEMEM + MEMORY_HOTPLUG
Signed-off-by: Mike Kravetz <[EMAIL PROTECTED]>
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
include/asm-pp
Adds the necessary for non-NUMA hot-add of highmem
to an existing zone on i386.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
memhotplug-dave/arch/i386/mm/discontig.c |4 +-
memhotplug-dave/arch/i386/mm/init.c | 61 ---
mm/hig
The following patches are apply to 2.6.13-rc6, or to 2.6.13-rc5-mm1 (if
you back out the existing sparsemem-extreme.patch and apply the stuff I
posted yesterday). Barring any serious objections, I think they're just
about ready for a run in -mm.
The following series implements memory hot-add for
See the "fixup bad_range()" patch for more information, but this
actually creates a the lock to protect things making assumptions
about a zone's size staying constant at runtime.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
memhotplug-dave/include/linux/me
This is unused, except for in an alpha header. Keep the alpha
one, kill the rest.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
memhotplug-dave/include/asm-i386/mmzone.h |6 --
memhotplug-dave/include/asm-m32r/mmzone.h |6 --
memhotplug-dave/include/asm-
A little helper that we use in the hotplug code.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
memhotplug-dave/include/linux/mmzone.h | 26 ++
mm/sparse.c|0
2 files changed, 26 insertions(+)
diff -puN include/linux/mmzon
- lru_add_drain() should be called before try_to_migrate_pages()
The following patch deals with the first item.
Signed-off-by: IWAMOTO Toshihiro <[EMAIL PROTECTED]>
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
memhotplug-dave/mm/memory_hotplug.c |2 ++
mm/page_alloc.c
page now. :)
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
memhotplug-dave/mm/page_alloc.c | 98 +++-
1 files changed, 58 insertions(+), 40 deletions(-)
diff -puN mm/page_alloc.c~C1-pcp_zone_init mm/page_alloc.c
--- memhotplug/mm/page_allo
nly place that I can find is bad_range().
So, split bad_range() up into two pieces: one that needs to be locked
and anther that doesn't.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
memhotplug-dave/mm/page_alloc.c | 26 +-
1 files changed, 21 insertions(+
On Wed, 2005-08-17 at 12:45 -0500, Adam Litke wrote:
> The line-wrapping in most of the include/asm/pgtable.h pte test/set
> macros looks horrible in my 80 column terminal. The following "test the
> waters" patch is how I would like to see them laid out. I realize that
> the braces don't adhere t
On Wed, 2005-04-20 at 16:30 +0200, Arjan van de Ven wrote:
> Why do you want this exported to userspace? There is absolutely no way
> you can get this exported race free without shutting the VM down, and
> without being race free this information has absolutely no meaning !!
> (and when you shut th
On Wed, 2005-04-20 at 14:34 +0200, Arjan van de Ven wrote:
> On Wed, 2005-04-20 at 21:02 +0900, KAMEZAWA Hiroyuki wrote:
> > Hi,
> >
> > There are several types of PG_reserved pages,
> > (a) Memory Hole
> > (b) Used by Kernel
> > (c) Set by drivers
> > (d) Isorated by MCA
> > (e) used by perfmon
>
On Thu, 2005-07-07 at 10:14 -0700, Martin Knoblauch wrote:
> Basically I saw that the only difference between me and Pekka was the
> FW (discounting the different CPU speed and Kernel version). I googled
> around and found the IBM FW page at:
>
> http://www-306.ibm.com/pc/support/site.wss/documen
On Thu, 2005-07-07 at 19:27 +0200, Jens Axboe wrote:
> On Thu, Jul 07 2005, Clemens Koller wrote:
> > Well, sure, it's not a notebook HDD, but maybe it's possible
> > to give headpark a more generic way to get the heads parked?
>
> This _is_ the generic way, if your drive doesn't support it you ar
On Thu, 2005-07-07 at 14:01 -0400, Lee Revell wrote:
> On Thu, 2005-07-07 at 10:38 -0700, Dave Hansen wrote:
> > On Thu, 2005-07-07 at 19:27 +0200, Jens Axboe wrote:
> > > This _is_ the generic way, if your drive doesn't support it you are out
> > > of luck.
>
On Wed, 2005-07-27 at 18:31 -0700, Ravikiran G Thirumalai wrote:
> On Wed, Jul 27, 2005 at 06:17:24PM -0700, Andrew Morton wrote:
> > Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
> > >
> > > While reserving KVA for lmem_maps of node, we have to make sure that
> > > node_remap_start_pfn[] is al
On Thu, 2005-07-28 at 11:14 -0700, Ravikiran G Thirumalai wrote:
> SRAT need not guarantee any alignment at all in the memory affinity
> structure (the address in 64-bit byte address)
The Summit machines (the only x86 user of the SRAT) have other hardware
guarantees about alignment, so I guess th
e.
It would be great if this could make it into 2.6.13, I think it counts
as a bugfix.
Tested on a 16-proc 4-node NUMAQ.
-- Dave
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
memhotplug-dave/arch/i386/kernel/numaq.c |9 +
1 files changed, 9 insertions(+)
diff -puN arch/i386/m
On Mon, 2005-08-01 at 04:07 -0400, Yani Ioannou wrote:
> Well don't forget there is a bios 'calibration' routine that you will
> see on start up (especially if you are on a moving vehicle/train).
I've never seen that. Could you please elaborate on what you see, and
when?
-- Dave
-
To unsubscrib
On Thu, 2005-08-18 at 17:15 -0400, Adam Goode wrote:
> On Thu, 2005-08-18 at 22:49 +0200, Pavel Machek wrote:
> > Please make it "echo 1 > frozen", then userspace can do "echo 0 > frozen"
> > after five seconds.
>
> What if the code to do "echo 0 > frozen" is swapped out to disk? ;)
In the real wo
I noticed that my cross-compilation 'make install' broke with 2.6.13 (I
don't use it horribly often). It's from this commit:
http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0f8e2d62fa04441cd12c08ce521e84e5bd3f8a46
Which added CROSS_COMPILE to each arch's
Adds the necessary for non-NUMA hot-add of highmem
to an existing zone on i386.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
memhotplug-dave/arch/i386/mm/discontig.c |4 +-
memhotplug-dave/arch/i386/mm/init.c | 61 ---
2 files changed, 58 inse
I made sure these apply to 2.6.13-mm1, just after
vm-add-page_state-info-to-per-node-meminfo.patch
But, they should apply anywhere after the ppc64 sparsemem extreme fixes
that went into 2.6.13-mm1.
--
The following series implements memory hot-add for ppc64 and i386.
There are x86_64 a
page now. :)
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
memhotplug-dave/mm/page_alloc.c | 98 +++-
1 files changed, 58 insertions(+), 40 deletions(-)
diff -puN mm/page_alloc.c~C1-pcp_zone_init mm/page_alloc.c
--- memhotplug/mm/page_allo
removed. The lock is
only required when doing pfn_valid() operations on memory which the
user does not already have a reference on the page, such as in
show_mem().
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
memhotplug-dave/arch/alpha/mm/numa.c |3 ++
memhotplug-dav
.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
memhotplug-dave/mm/memory_hotplug.c | 43
memhotplug-dave/mm/sparse.c | 74 +---
2 files changed, 70 insertions(+), 47 deletions(-)
diff -puN mm/memory_hotplug.
See the "fixup bad_range()" patch for more information, but this
actually creates a the lock to protect things making assumptions
about a zone's size staying constant at runtime.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
memhotplug-dave/include/linux/me
This is unused, except for in an alpha header. Keep the alpha
one, kill the rest.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
memhotplug-dave/include/asm-i386/mmzone.h |6 --
memhotplug-dave/include/asm-m32r/mmzone.h |6 --
memhotplug-dave/include/asm-
We'll fix it up properly once
it calms down.
Signed-off-by: Matt Tolentino <[EMAIL PROTECTED]>
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
memhotplug-dave/drivers/base/Makefile |1
memhotplug-dave/drivers/base/init.c|2
memhotplug-dave
Here is a set of ppc64 specific patches that at least allow
compilation/booting with the following configurations:
FLATMEM
SPARSEMEN
SPARSEMEM + MEMORY_HOTPLUG
Signed-off-by: Mike Kravetz <[EMAIL PROTECTED]>
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
memhotplug-dave/a
- lru_add_drain() should be called before try_to_migrate_pages()
The following patch deals with the first item.
Signed-off-by: IWAMOTO Toshihiro <[EMAIL PROTECTED]>
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
memhotplug-dave/mm/memory_hotplug.c |2 ++
1 files changed, 2 inse
A little helper that we use in the hotplug code.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
memhotplug-dave/include/linux/mmzone.h | 25 +
1 files changed, 25 insertions(+)
diff -puN include/linux/mmzone.h~C3-__section_nr include/linux/mmzone.h
--- memh
nly place that I can find is bad_range().
So, split bad_range() up into two pieces: one that needs to be locked
and anther that doesn't.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
memhotplug-dave/mm/page_alloc.c | 26 +-
1 files changed, 21 insertions(+
On Fri, 2005-09-02 at 15:13 -0700, Andrew Morton wrote:
> Dave Hansen <[EMAIL PROTECTED]> wrote:
> >
> > + for (i = 0; i < PAGES_PER_SECTION; i++) {
> > + if (PageReserved(first_page+i))
> > + continue;
&g
On Sat, 2005-09-03 at 09:50 +0100, Ian Campbell wrote:
> > Could we do something that's guaranteed to not have lots of extra
> path
> > elements in it, like ARCH?
>
> Or perhaps basename ${CROSSCOMPILE}?
The only problem with that is that some people do really have a cross
compiler named /usr/ppc
On Wed, 2005-09-07 at 02:37 -0700, Andrew Morton wrote:
> Dave Hansen <[EMAIL PROTECTED]> wrote:
> >
> > --- memhotplug/include/asm-x86_64/mmzone.h~C0-kill-local_mapnr
> > 2005-08-18 14:59:43.0 -0700
> > +++ memhotplug-dave/include/asm-x86_64/
On Tue, 2005-09-06 at 12:56 +0900, Magnus Damm wrote:
> This patch for 2.6.13-git5 fixes single node sparsemem support. In the case
> when multiple nodes are used, setup_memory() in arch/i386/mm/discontig.c calls
> get_memcfg_numa() which calls memory_present(). The single node case with
> setup_me
On Wed, 2005-09-07 at 11:22 -0700, Martin J. Bligh wrote:
> CONFIG_NUMA was meant to (and did at one point) support both NUMA and flat
> machines. This is essential in order for the distros to support it - same
> will go for sparsemem.
That's a different issue. The current code works if you boot
On Wed, 2005-09-07 at 17:35 -0500, linas wrote:
> On Fri, Sep 02, 2005 at 01:39:13PM -0700, Dave Hansen was heard to remark:
> > I noticed that my cross-compilation 'make install' broke with 2.6.13 (I
> > don't use it horribly often). It's from this commit:
&g
page_alloc.c currently has two implementations of build_zonelists()
based on a CONFIG_NUMA #ifdef. Does anybody see a reason to keep
the !NUMA one? The NUMA version uses one more global __init
variable than the flat one. But, all of its extra loops should
optimize down to nothing when NUMA is o
On Wed, 2005-09-07 at 16:49 -0700, Andrew Morton wrote:
> "Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
> > Ah, OK - makes more sense. However, some machines do have large holes
> > in e820 map setups - is not really critical, more of an efficiency
> > thing.
>
> Confused. Does all this mean that
This is in response to:
Subject: Re: 2.6.13-mm2 high memory support borken?
This should fix it. It was simply missing the call to free_new_highpage.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
memhotplug-dave/arch/i386/mm/init.c |1 +
1 files changed, 1 insertion(+)
dif
atomic_inc() even if
> cpu_writer was passed in as NULL, the patch seems good.
Yeah, I screwed that up. Should be fixed now.
> > Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
> > ---
> >
> > linux-2.6.git-dave/fs/file_table.c | 24 -
&g
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 nr_user_mounts;
> +int
On Tue, 2008-01-08 at 12:35 +0100, Miklos Szeredi wrote:
> +static int reserve_user_mount(void)
> +{
> + int err = 0;
> +
> + spin_lock(&vfsmount_lock);
> + if (nr_user_mounts >= max_user_mounts && !capable(CAP_SYS_ADMIN))
> + err = -EPERM;
> + else
> +
On Tue, 2008-01-08 at 12:35 +0100, Miklos Szeredi wrote:
> @@ -510,10 +533,16 @@ static struct vfsmount *clone_mnt(struct
> int flag)
> {
> struct super_block *sb = old->mnt_sb;
> - struct vfsmount *mnt = alloc_vfsmnt(old->mnt_devname);
> +
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 p
On Tue, 2008-01-08 at 13:10 -0800, [EMAIL PROTECTED] wrote:
> 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.
I guess I just don't really see the point of moving the code around like
this. Before, it would have been eas
On Wed, 2008-01-09 at 10:30 -0800, Yinghai Lu wrote:
>
> [PATCH] x86_64: cleanup setup_node_zones called by paging_init v2
>
> setup_node_zones calcuates some variable but only use them when
> FLAT_NODE_MEM_MAP is set
>
> so change the MACRO postion to avoid calculating.
>
> also change it to s
On Wed, 2008-01-09 at 11:31 -0800, Christoph Lameter wrote:
> Well this is only the first patchset. The next one will unify this even
> more (and make percpu functions work consistent between the two arches)
> but it requires changes to the way the %gs register is used in
> x86_64. So we only do
We need to make sure that all mounts get into the
sb list. So, require that new setters of mnt->mnt_sb
use simple_set_mnt() instead of doing it themselves.
NFS does the same thing a few times in a row, so give
it a nice little helper.
---
linux-2.6.git-dave/fs/namespace.c |3 +--
linux-2.
---
linux-2.6.git-dave/fs/namespace.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff -puN fs/namespace.c~change-spinlock-to-mutex fs/namespace.c
--- linux-2.6.git/fs/namespace.c~change-spinlock-to-mutex 2008-01-10
10:45:47.0 -0800
+++ linux-2.
This is just RFC for now. I'm tracking down a wee bit of
list corruption. But, I wanted to send out so you could
compare to the last approach.
--
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://v
d-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
linux-2.6.git-dave/fs/namespace.c| 28 ++
linux-2.6.git-dave/fs/super.c| 58 ---
linux-2.6.git-dave/include/linux/fs.h|1
linux-2.6.git-dave/include/linux/mount.h |3 +
4
time, __mnt_writers can only underflow by
MNT_WRITER_UNDERFLOW_LIMIT+NR_CPUS.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
linux-2.6.git-dave/fs/namespace.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff -puN fs/namespace.c~change-underflow-protection-logic
Missed the description on that one. Here it is:
We're shortly going to need to be able to block new
mnt_writers for long periods of time during a
superblock remount operation. Since this operation
can sleep, we can not use a spinlock. We opt for
a mutex instead.
This are very, very rarely cont
On Thu, 2007-12-06 at 11:01 +0100, Jan Blunck wrote:
> > Rather than give each _dirent_ an offset, could we give each sub-mount
> > an offset? Let's say we have three members comprising a union mount
> > directory. The first has 100 dirents, the second 200, and the third
> > 10,000. When the fir
On Tue, 2008-01-22 at 13:02 -0800, Andrew Morton wrote:
> > WARNING: at fs/file_table.c:49 __fput+0x1a8/0x1e0()
> > Modules linked in: sg sr_mod cdrom
> > Call Trace:
> > [004c9ac8] __fput+0x1b0/0x1e0
> > [004c6978] filp_close+0x60/0x80
> > [004c6a18] sys_close+0x80/0xe0
ning that would
have otherwise been triggered.
I also wonder if inode->i_writecount is made inconsistent
by the emergency remount code. I guess it is, but the
damage is limited to a single inode instead of being
visible more globally like the mnt write count. Probably
not really worth fixing
On Wed, 2008-01-23 at 11:04 -0500, Mathieu Desnoyers wrote:
> Since memory management is not my speciality, I would like to know if
> there are some implementation details I should be aware of for my
> LTTng userspace tracing buffers. Here is what I want to do :
Can you start with a little backgro
On Thu, 2008-01-24 at 18:09 +0100, Cedric Le Goater wrote:
> yes but we would need more something like :
>
> long sys_clone64(unsigned long flags_high, unsigned long flag_low)
>
> if we want the syscall to be supported on 32bit arch. clone2 is also
> being used on ia64 already.
Did we decide
On Thu, 2008-01-24 at 18:37 +0100, Pavel Machek wrote:
> > Did we decide not to do something with a variable number of
> arguments?
> >
> > sys_clonefoo(unsigned long *flags, int len);
>
> That is evil, because that means strace can no longer reliably print
> flags being used (for example).
On Wed, 2007-10-03 at 10:31 +0900, KAMEZAWA Hiroyuki wrote:
>
> i386 and x86_64 registers System RAM as IORESOUCE_MEM |
> IORESOUCE_BUSY.
> ia64 registers System RAM as IORESOURCE_MEM.
>
> Which is better ?
I think we should take system ram out of the iomem file, at least.
'struct resource' is
On Wed, 2007-10-03 at 08:47 -0700, Adam Litke wrote:
> When shrinking the size of the hugetlb pool via the nr_hugepages sysctl, we
> are careful to keep enough pages around to satisfy reservations. But the
> calculation is flawed for the following scenario:
>
> Action Poo
On Wed, 2007-10-03 at 13:33 -0500, Adam Litke wrote:
> On Wed, 2007-10-03 at 10:40 -0700, Dave Hansen wrote:
> > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > > index 84c795e..7af3908 100644
> > > --- a/mm/hugetlb.c
> > > +++ b/mm/hugetlb.c
> > > @
g
the nameidata_to_filp() calls into namei.c, and this
gets the sys_open flags to a place where we can get
at them when we need them.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
lxc-dave/fs/namei.c | 43 ++-
lxc-dave/fs/open.c | 22 ++
is. Any caller
getting a 'struct file' back must consider that filp instantiated
and fput() it normally. The callers no longer have to worry about
ever manually releasing a mnt write count.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
lxc-dave/fs/namei.c | 16 +
Replace all callers with open_namei() directly, and move the
nameidata stack allocation into open_namei().
Does it make sense to still call it open_namei(), even though it
doesn't actually take a nameidata any more?
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
lxc-dave/
This kills off the almost empty do_filp_open(). The indenting
change in do_sys_open() is because we would have gone over our
80 characters otherwise.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
lxc-dave/fs/open.c | 39 ++-
1 file chang
op us from having any oopses or mnt_writer
count imbalances.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
lxc-dave/fs/file_table.c| 21 +++--
lxc-dave/fs/open.c |2 ++
lxc-dave/include/linux/fs.h |4
3 files changed, 25 insertions(+), 2 de
pen() into __dentry_open(), where we should catch
many more of the users.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
lxc-dave/fs/namei.c | 12
lxc-dave/fs/open.c | 45 ++---
2 files changed, 38 insertions(+), 19 deletions(-)
diff -pu
---
lxc-dave/fs/file_table.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff -puN fs/file_table.c~init_file-only-take-writes-on-normal-files
fs/file_table.c
--- lxc/fs/file_table.c~init_file-only-take-writes-on-normal-files
2007-10-04 13:01:59.0 -0700
+++ lxc
On Thu, 2007-10-11 at 17:08 +0200, Miklos Szeredi wrote:
> > diff -puN fs/namei.c~get-write-in-__dentry_open fs/namei.c
> > --- lxc/fs/namei.c~get-write-in-__dentry_open 2007-10-03
> > 14:44:52.0 -0700
> > +++ lxc-dave/fs/namei.c 2007-10-04 18:02:48.0 -0700
> > @@ -1621,1
On Thu, 2007-10-11 at 20:31 +0200, Miklos Szeredi wrote:
> > On Thu, 2007-10-11 at 17:08 +0200, Miklos Szeredi wrote:
> > > > diff -puN fs/namei.c~get-write-in-__dentry_open fs/namei.c
> > > > --- lxc/fs/namei.c~get-write-in-__dentry_open 2007-10-03
> > > > 14:44:52.0 -0700
> > > > +++ l
On Wed, 2007-12-26 at 15:12 +0100, Christoph Hellwig wrote:
> Btw, I just noticed in current -mm fs_may_remount_ro() is still around
> and not replaced by ther per-sb writers count. That surely sounds like
> some kind of mismerge..
I was actually leaving that for later. Getting rid of the filp s
On Mon, 2007-12-31 at 11:54 -0800, Dave Hansen wrote:
> On Wed, 2007-12-26 at 15:12 +0100, Christoph Hellwig wrote:
> > Btw, I just noticed in current -mm fs_may_remount_ro() is still around
> > and not replaced by ther per-sb writers count. That surely sounds like
> >
e sb's writable mounts during a remount.
The alternative to doing this is to do a much simpler list
of mounts for each superblock. I could also code that up
to see what it look like. Shouldn't be too bad.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
linux-2.6.gi
On Wed, 2007-11-28 at 09:09 -0500, Mathieu Desnoyers wrote:
> ===
> --- linux-2.6-lttng.orig/mm/filemap.c 2007-11-28 08:38:46.0 -0500
> +++ linux-2.6-lttng/mm/filemap.c 2007-11-28 08:59:05.0 -0500
> @@ -514,9 +514,
On Wed, 2007-11-28 at 00:41 -0800, Andrew Morton wrote:
> Given that nameidata_to_filp() can call path_release() which "destroys the
> original nameidata", it looks like this was always buggy?
It does. I can see how I introduced the bug, and your fix does look
like a good one. Thanks.
-- Dave
On Wed, 2007-11-28 at 21:34 -0500, Mathieu Desnoyers wrote:
> Before I start digging deeper in checking whether it is already
> instrumented by the fs instrumentation (and would therefore be
> redundant), is there a particular data structure from mm/ that you
> suggest taking the swap file number a
This looks fine now.
Acked-by: Dave Hansen <[EMAIL PROTECTED]>
-- Dave
-
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
On Fri, 2007-11-30 at 12:05 -0500, Mathieu Desnoyers wrote:
>
>
> Given a trace including :
> - Swapfiles initially used
> - multiple swapon/swapoff
> - swap in/out events
>
> We would like to be able to tell which swap file the information has
> been written to/read from at any given time durin
On Fri, 2007-11-30 at 11:11 -0500, Mathieu Desnoyers wrote:
> +static inline swp_entry_t page_swp_entry(struct page *page)
> +{
> + swp_entry_t entry;
> + VM_BUG_ON(!PageSwapCache(page));
> + entry.val = page_private(page);
> + return entry;
> +}
This probably needs to be i
On Tue, 2007-12-04 at 16:23 +0100, Joerg Roedel wrote:
>
> -#define _PAGE_FILE 0x040 /* nonlinear file mapping, saved PTE;
> unset:swap */
> -#define _PAGE_GLOBAL 0x100 /* Global TLB entry */
> +#define _PAGE_PRESENT (_AC(1, UL)<<_PAGE_BIT_PRESENT)
> +#define _PAGE_RW (_AC(1, UL)<
501 - 600 of 5336 matches
Mail list logo
