On Sat, 2008-02-02 at 18:37 +0900, KOSAKI Motohiro wrote:
> Hi Andi,
>
> > > 3. 2.6.24-rc8-mm1 set_mempolicy(2) behavior
> > >3.1 check nodesubset(nodemask argument, node_states[N_HIGH_MEMORY])
> > >in mpol_check_policy()
> > >
> > > -> check failed when memmoryless node exist.
> >
On Tue, 2008-02-05 at 14:31 +, Mel Gorman wrote:
> On (04/02/08 13:20), Lee Schermerhorn didst pronounce:
> > > > When the kernel behaviour changes and breaks user space then the kernel
> > > > is usually wrong. Cc'ed Lee S. who maintains the kernel code no
On Tue, 2008-02-05 at 10:12 -0800, Christoph Lameter wrote:
> Could we focus on the problem instead of discussion of new patches under
> development?
Christoph: you are free to ignore any part of this discussion that you
wish...
> Can we confirm that what Kosaki sees is a bug?
by definition,
tlbfs policies--if/when we fold
mpol_check_policy() into mpol_new(), as you suggested. Once we can
agree on the desired semantics, I had been thinking that an additional
mode flag could be added to policies obtained from the superblock, and
passed via mpol_shared_policy_init() [which calls mpol_new(
On Sat, 2008-02-09 at 23:42 -0800, Linus Torvalds wrote:
>
> On Sat, 9 Feb 2008, Greg KH wrote:
> >
> > Once the patch goes into Linus's tree, feel free to send it to the
> > [EMAIL PROTECTED] address so that we can include it in the 2.6.24.x
> > tree.
>
> I've been ignoring the patches because
before return?
> >
>
> Very good catch!
>
>
>
> mempolicy: fix policy memory leak in mpol_new()
>
> If mpol_new() cannot setup a new mempolicy because of an invalid argument
> provided by the user, avoid leaking the mempolicy that has been dynamically
> alloc
o policy in
shmem_parse_mpol() and test in mpol_new(). If we want to be able to
specify existing or new behavior, we can use the same flag, but set it
or not based on an additional qualifier specified via the mount option.
[more below]
>
> Cc: Paul Jackson <[EMAIL PROTECTED]>
> Cc
>
> although the only possible values is the range of type unsigned short.
>
> Cc: Paul Jackson <[EMAIL PROTECTED]>
> Cc: Christoph Lameter <[EMAIL PROTECTED]>
> Cc: Lee Schermerhorn <[EMAIL PROTECTED]>
> Cc: Andi Kleen <[EMAIL PROTECTED]>
> Signed-of
g optional mode flags, it will need to use
> mpol_mode() in switch and conditional statements that only test mode.
> Cc: Paul Jackson <[EMAIL PROTECTED]>
> Cc: Christoph Lameter <[EMAIL PROTECTED]>
> Cc: Lee Schermerhorn <[EMAIL PROTECTED]>
> Cc: Andi Kleen <[EM
On Mon, 2008-02-11 at 11:34 -0800, David Rientjes wrote:
> On Mon, 11 Feb 2008, Lee Schermerhorn wrote:
>
> > These patches look good--well, interesting, anyway. I'm "off on
> > assignment" this week, so I won't get to review in detail, merge and
> >
On Tue, 2008-02-12 at 20:18 -0800, David Rientjes wrote:
> On Tue, 12 Feb 2008, Lee Schermerhorn wrote:
>
> > > Adds another member to struct mempolicy,
> > >
> > > nodemask_t user_nodemask
> > >
> > > that stores the the nodemask th
On Tue, 2008-02-12 at 21:06 -0800, David Rientjes wrote:
> On Tue, 12 Feb 2008, David Rientjes wrote:
>
> > Since we're allowed to remap the node to a different node than the user
> > specified with either syscall, the current behavior is that "one node is
> > as good as another." In other word
On Wed, 2008-02-13 at 01:36 -0800, David Rientjes wrote:
> On Wed, 13 Feb 2008, Paul Jackson wrote:
>
> > The infamous unpublished (except to a few) patch I drafted on Christmas
> > (Dec 25, 2007) basically added two new modes for how mempolicy
> > nodemasks were to be resolved:
> > 1) a static,
On Wed, 2008-02-13 at 10:48 -0800, David Rientjes wrote:
> On Wed, 13 Feb 2008, Lee Schermerhorn wrote:
>
> > > > 2) Those 'mpol_mode()' wrappers on all those mempolicy->policy
> > > > evaluations look dangerous to me. It looks like a code bug
&g
nt check for memoryless nodes from
mpol_check_policy().
4) remove the masking of policy nodes for interleave policy from
mpol_new().
Signed-off-by: Lee Schermerhorn <[EMAIL PROTECTED]>
mm/mempolicy.c | 18 --
1 file changed,
On Tue, 2008-02-05 at 15:33 -0600, Paul Jackson wrote:
> David wrote:
> > It would be disappointing to see a lot of work done to fix
>
> The suggested patch of KOSAKI Motohiro didn't look like a lot of work to me.
>
> I continue to prefer not to hijack this thread for that other discussion.
> Jus
On Tue, 2008-02-05 at 14:12 -0800, Christoph Lameter wrote:
> On Tue, 5 Feb 2008, Lee Schermerhorn wrote:
>
> > mbind(2), on the other hand, just masks off any nodes in the
> > nodemask that are not included in the caller's mems_allowed.
>
> Ok so we temporar
On Tue, 2008-02-05 at 18:17 -0800, David Rientjes wrote:
> On Tue, 5 Feb 2008, Lee Schermerhorn wrote:
>
> > Index: Linux/mm/mempolicy.c
> > ===
> > --- Linux.orig/mm/mempolicy.c 2008-02-05
) and restores some error checking that the
memoryless-nodes series lost when restricting node masks to
allowed_nodes [== subset of nodes with memory].
4) remove the now redundant masking of policy nodes for interleave
policy from mpol_new().
Signed-off-by: Lee Schermerhorn <[EM
() contextualizes the nodemask, remove
the in-line nodes_and() from sys_mbind(). I believe that this
restores mbind() to the behavior before the memoryless-nodes
patch series. E.g., we'll no longer treat an invalid nodemask
with MPOL_PREFERRED as local allocation.
Signed-off-by: Lee S
that caused
the problem in 23-rc6-mm1? If not, I wouldn't think this patch is
necessary there.
Lee
>
> ----------
>
> From: Lee Schermerhorn <[EMAIL PROTECTED]>
>
> mainline: a683d652d334a546be9175b894f42dbd8e399536
>
> New scatter/gather list chaini
25-rc2-mm1 is hanging early in boot on my HP ia64 numa platform. I saw
the "Strange hang on ia64 with CONFIG_PRINTK_TIME=y" thread on lkml:
http://marc.info/?t=12028839681&r=1&w=4
However, my config does not include PRINTK_TIME=y. In fact, hang occurs
with ia64 defconfig as well--
On Fri, 2012-07-06 at 12:38 -0400, Rik van Riel wrote:
> On 03/23/2012 07:50 AM, Mel Gorman wrote:
> > On Fri, Mar 16, 2012 at 03:40:31PM +0100, Peter Zijlstra wrote:
> >> From: Lee Schermerhorn
> >>
> >> This patch adds another mbind() flag to request "laz
heir own LRUs, so the system only scans the pages that it
>can/should evict from memory
>
> 3) switching to SEQ replacement for the anonymous LRUs, so the
>number of pages that need to be scanned when the system
>starts swapping is bound to a reasonable number
>
> T
On Thu, 2008-01-03 at 12:00 -0500, Rik van Riel wrote:
> On Thu, 03 Jan 2008 11:52:08 -0500
> Lee Schermerhorn <[EMAIL PROTECTED]> wrote:
>
> > Also, I should point out that the full noreclaim series includes a
> > couple of other patches NOT posted here by Rik:
&g
On Thu, 2008-01-03 at 17:00 -0500, Rik van Riel wrote:
> On Thu, 03 Jan 2008 12:13:32 -0500
> Lee Schermerhorn <[EMAIL PROTECTED]> wrote:
>
> > Yes, but the problem, when it occurs, is very awkward. The system just
> > hangs for hours/days spinning on the rev
On Fri, 2008-01-04 at 17:34 +0100, Andi Kleen wrote:
> Lee Schermerhorn <[EMAIL PROTECTED]> writes:
>
> > We can easily [he says, glibly] reproduce the hang on the anon_vma lock
>
> Is that a NUMA platform? On non x86? Perhaps you just need queued spinlocks?
We see t
On Tue, 2007-12-11 at 20:21 +, Mel Gorman wrote:
> This is a rebase of the two-zonelist patchset to 2.6.24-rc4-mm1 and some
> warnings cleared up. The warnings were not picked up before as they were
> introduced early in the set and cleared up by the end. This might have hurt
> bisecting so wer
On Thu, 2007-12-13 at 09:23 +0900, KAMEZAWA Hiroyuki wrote:
> On Wed, 12 Dec 2007 16:32:51 -0500
> Lee Schermerhorn <[EMAIL PROTECTED]> wrote:
>
> > Just this afternoon, I hit a null pointer deref in
> > __mem_cgroup_remove_list() [called from mem_cgroup_uncharge() i
On Fri, 2008-01-18 at 12:19 -0800, Greg KH wrote:
> On Fri, Jan 18, 2008 at 03:12:33PM -0500, Lee Schermerhorn wrote:
> > I searched around the archives and web and didn't find any reports on
> > this [maybe just missed them?], so I MUST be doing something
> > wrong/st
I searched around the archives and web and didn't find any reports on
this [maybe just missed them?], so I MUST be doing something
wrong/stupid. My config [included] may be the culprit. Apologies for
the long cc list. I'm copying the kprobes and blktrace maintainers
[addresses from MAINTAINERS]
On Tue, 2007-10-02 at 16:36 +0900, KAMEZAWA Hiroyuki wrote:
> On Tue, 2 Oct 2007 00:18:09 -0700
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> > >
> > > > How come? Memoryless node can and do occur in real-world machines.
> > > > Kernel
> > > > should support that?
> > >
> > > But a node is just
On Tue, 2007-10-02 at 00:43 -0700, Andrew Morton wrote:
> On Tue, 2 Oct 2007 16:36:24 +0900 KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 2 Oct 2007 00:18:09 -0700
> > Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > How come? Memoryless node can and do occur in real-world
also
> specify GFP_THISNODE. In this case, only the specified node should be used.
> This patch will allocate pages only from the requested node when GFP_THISNODE
> is used with alloc_pages_node().
>
> [EMAIL PROTECTED]: Detailed analysis of problem]
> Found-by: Lee Schermerhorn <[EM
On Thu, 2007-12-20 at 10:33 -0500, Rik van Riel wrote:
> On Wed, 19 Dec 2007 23:19:00 -0800 (PST)
> Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 19 Dec 2007, Nick Piggin wrote:
> >
> > > These mlocked pages don't need to be on a non-reclaimable list,
> > > because we can find them a
BNX2X config option to 'select ZLIB_INFLATE' like BNX2
and others. This seems to fix it.
Signed-off-by: Lee Schermerhorn <[EMAIL PROTECTED]>
drivers/net/Kconfig |1 +
1 file changed, 1 insertion(+)
Index: Linu
Just a "heads up": This patch is the apparent cause of a boot time
panic--null pointer deref--on my numa platform. See below.
On Tue, 2007-11-27 at 12:00 +0900, KAMEZAWA Hiroyuki wrote:
> Counting active/inactive per-zone in memory controller.
>
> This patch adds per-zone status in memory cgrou
On Thu, 2007-11-29 at 14:24 +0900, KAMEZAWA Hiroyuki wrote:
> On Thu, 29 Nov 2007 12:23:29 +0900
> KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> > I noticed CONFIG_NUMA + CONFIG_CGROUP_MEM_CONT + CONFIG_SLUB cannot boot
> > because of my patch.
> > (SLAB is ok.)
> > I'll post workaround soon.
> >
On Fri, 2007-11-09 at 14:33 +, Mel Gorman wrote:
> Filtering zonelists requires very frequent use of zone_idx(). This is costly
> as it involves a lookup of another structure and a substraction operation. As
> the zone_idx is often required, it should be quickly accessible. The node
> idx coul
On Tue, 2007-11-20 at 14:19 +, Mel Gorman wrote:
> On (09/11/07 07:45), Christoph Lameter didst pronounce:
> > On Fri, 9 Nov 2007, Mel Gorman wrote:
> >
> > > struct page * fastcall
> > > __alloc_pages(gfp_t gfp_mask, unsigned int order,
> > > struct zonelist *zonelist)
> > > {
>
On Wed, 2007-11-21 at 13:12 -0500, Lee Schermerhorn wrote:
> Mel:
>
> Are the comparisons noted below correct--i.e., '>' rather than '<'? I'm
> trying to understand how this matches the comments and code. Doesn't
> look right to me, but I could
Mel:
Are the comparisons noted below correct--i.e., '>' rather than '<'? I'm
trying to understand how this matches the comments and code. Doesn't
look right to me, but I could be missing something.
Lee
On Wed, 2007-11-21 at 00:40 +, Mel Gorman wrote:
> Filtering zonelists requires very fr
On Wed, 2007-11-21 at 13:18 -0500, Lee Schermerhorn wrote:
> On Wed, 2007-11-21 at 13:12 -0500, Lee Schermerhorn wrote:
> > Mel:
> >
> > Are the comparisons noted below correct--i.e., '>' rather than '<'? I'm
> > trying to understand
On Fri, 2008-01-11 at 15:24 +0900, KOSAKI Motohiro wrote:
> Hi Rik
>
> > +static inline int is_file_lru(enum lru_list l)
> > +{
> > + BUILD_BUG_ON(LRU_INACTIVE_FILE != 2 || LRU_ACTIVE_FILE != 3);
> > + return (l/2 == 1);
> > +}
>
> below patch is a bit cleanup proposal.
> i think LRU_FILE is
doing. I left the default == NO during
development/experimemental stage so that one would have to take explicit
action to enable this function. If the feature makes it into mainline
and we decide that the default should be 'yes', that will be an easy
change.
Thanks for looking at th
On Fri, 2008-01-11 at 10:42 -0500, Rik van Riel wrote:
> On Fri, 11 Jan 2008 15:24:34 +0900
> KOSAKI Motohiro <[EMAIL PROTECTED]> wrote:
>
> > below patch is a bit cleanup proposal.
> > i think LRU_FILE is more clarify than "/2".
> >
> > What do you think it?
>
> Thank you for the cleanup, your
On Fri, 2008-01-11 at 11:15 -0500, Rik van Riel wrote:
> On Fri, 11 Jan 2008 10:59:18 -0500
> Lee Schermerhorn <[EMAIL PROTECTED]> wrote:
>
> > On Fri, 2008-01-11 at 10:42 -0500, Rik van Riel wrote:
> > > On Fri, 11 Jan 2008 15:24:34 +0900
> > > KO
On Wed, 2007-12-19 at 11:48 +1100, Nick Piggin wrote:
> On Wednesday 19 December 2007 08:15, Rik van Riel wrote:
> > 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 pa
On Wed, 2007-12-19 at 08:45 -0500, Rik van Riel wrote:
> On Wed, 19 Dec 2007 11:56:48 +1100
> Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > On Wednesday 19 December 2007 08:15, Rik van Riel wrote:
> >
> > > Rework of a patch by Nick Piggin -- part 1 of 2.
> > >
> > > This patch:
> > >
> > > 1) def
On Wed, 2007-12-19 at 09:53 -0500, Rik van Riel wrote:
> On Wed, 19 Dec 2007 15:24:07 +0100
> Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> > I thought Lee had patches that moved pages with long rmap chains (both
> > anon and file) out onto the non-reclaim list, for those a slow
> > background sca
On Wed, 2007-12-19 at 11:31 -0500, Rik van Riel wrote:
> On Wed, 19 Dec 2007 10:52:09 -0500
> Lee Schermerhorn <[EMAIL PROTECTED]> wrote:
>
> > I keep these patches up to date for testing. I don't have conclusive
> > evidence whether they alleviate or exacerbate
On Wed, 2008-01-30 at 17:57 +0900, KOSAKI Motohiro wrote:
> Hi Rik, Lee
>
> I found number of scan pages calculation bug.
>
> 1. wrong calculation order
>
> ap *= rotate_sum / (zone->recent_rotated_anon + 1);
>
>when recent_rotated_anon = 100 and recent_rotated_file = 0,
>
>
On Thu, 2007-10-25 at 17:28 -0700, Christoph Lameter wrote:
> On Thu, 25 Oct 2007, David Rientjes wrote:
>
> > The problem occurs when you add cpusets into the mix and permit the
> > allowed nodes to change without knowledge to the application. Right now,
> > a simple remap is done so if the ca
On Thu, 2007-10-25 at 19:11 -0700, David Rientjes wrote:
> On Thu, 25 Oct 2007, Paul Jackson wrote:
>
> > David - could you describe the real world situation in which you
> > are finding that this new 'interleave_over_allowed' option, aka
> > 'memory_spread_user', is useful? I'm not always oppose
On Thu, 2007-10-25 at 20:58 -0700, David Rientjes wrote:
> On Thu, 25 Oct 2007, Paul Jackson wrote:
>
> > The user space man pages for set_mempolicy(2) are now even more
> > behind the curve, by not mentioning that MPOL_INTERLEAVE's mask
> > might mean nothing, if (1) in a cpuset marked memory_spr
On Fri, 2007-10-26 at 10:04 -0700, Paul Jackson wrote:
> Lee wrote:
> > Paul: what do you think about subsetting the cpuset.txt into a man page
> > or 2 that can be referenced by other man pages' See Also sections?
>
> Oh dear --- looking back in my work queue I have with my employer, I
> see I h
On Fri, 2007-10-26 at 10:18 -0700, Paul Jackson wrote:
> pj wrote:
> > On a different point, we could, if it was worth the extra bit of code,
> > improve the current code's handling of mempolicy rebinding when the
> > cpuset adds memory nodes. If we kept both the original cpusets
> > mems_allowed,
On Fri, 2007-10-26 at 10:54 -0700, Paul Jackson wrote:
> > Will it handle the case of MPOL_INTERLEAVE policy on a shm segment that
> > is mapped by tasks in different, possibly disjoint, cpusets. Local
> > allocation does, and my patch does. That was one of the primary
> > goals--to address an is
On Fri, 2007-10-26 at 11:46 -0700, David Rientjes wrote:
> On Fri, 26 Oct 2007, Lee Schermerhorn wrote:
>
> > Actually, my patch doesn't change the set_mempolicy() API at all, it
> > just co-opts a currently unused/illegal value for the nodemask to
> > indicate "
On Fri, 2007-10-26 at 13:45 -0700, David Rientjes wrote:
> On Fri, 26 Oct 2007, Paul Jackson wrote:
>
> > Without at least this sort of change to MPOL_INTERLEAVE nodemasks,
> > allowing either empty nodemasks (Lee's proposal) or extending them
> > outside the current cpuset (what I'm cooking up no
On Fri, 2007-10-26 at 14:17 -0700, Christoph Lameter wrote:
> On Fri, 26 Oct 2007, Lee Schermerhorn wrote:
>
> > For some systems [not mine], the nodemasks can get quite large. I have
> > a patch, that I've tested atop Mel Gorman's "onezonelist" patches th
On Fri, 2007-10-26 at 14:18 -0700, David Rientjes wrote:
> On Fri, 26 Oct 2007, Lee Schermerhorn wrote:
>
> > You don't need to save the entire mask--just note that NODE_MASK_ALL was
> > passed--like with my internal MPOL_CONTEXT flag. This would involve
> > specia
On Fri, 2007-10-26 at 14:37 -0700, Christoph Lameter wrote:
> On Fri, 26 Oct 2007, Lee Schermerhorn wrote:
>
> > > > Now, if we could replace the 'cpuset_mems_allowed' nodemask with a
> > > > pointer to something stable, it might be a win.
> > >
On Fri, 2007-10-26 at 14:39 -0700, David Rientjes wrote:
> On Fri, 26 Oct 2007, Lee Schermerhorn wrote:
>
> > So, you pass the subset, you don't set the flag to indicate you want
> > interleaving over all available. You must be thinking of some other use
> > for sa
On Mon, 2007-10-29 at 10:33 -0700, Paul Jackson wrote:
> Lee wrote:
> > I only brought it up again because now you all are considering another
> > nodemask per policy.
>
> The patch David and I are discussing will replace the
> cpuset_mems_allowed nodemask in struct mempolicy, not
> add a new node
On Sat, 2007-10-27 at 12:16 -0700, David Rientjes wrote:
> On Fri, 26 Oct 2007, David Rientjes wrote:
>
> > Hacking and requiring an updated version of libnuma to allow empty
> > nodemasks to be passed is a poor solution; if mempolicy's are supposed to
> > be independent from cpusets, then what
On Sat, 2007-10-27 at 16:19 -0700, Paul Jackson wrote:
> David wrote:
> > I think there's a mixup in the flag name [MPOL_MF_RELATIVE] there
>
> Most likely. The discussion involving that flag name was kinda mixed up ;).
>
> > but I actually would recommend against any flag to effect Choice A.
>
On Mon, 2007-10-29 at 11:41 -0700, Paul Jackson wrote:
> Lee wrote:
> > Maybe it's just me, but I think it's pretty presumptuous to think we can
> > infer the intent of the application from the nodemask w/o additional
> > flags such as Christoph proposed [cpuset relative]--especially for
> > subset
On Tue, 2007-10-30 at 12:47 -0700, Paul Jackson wrote:
> Andi, Christoph, or whomever:
>
> Are there any good regression tests of mempolicy functionality?
Paul: Andi has a regression test in the numactl source package.
Try:
http://freshmeat.net/redir/numactl/62210/url_tgz/numactl-1.0.
On Thu, 2007-11-01 at 15:29 +0100, Nick Piggin wrote:
> On Thu, Nov 01, 2007 at 03:06:05PM +0100, Peter Zijlstra wrote:
> > On Thu, 2007-11-01 at 15:02 +0100, Nick Piggin wrote:
> >
> > > Rename need_lockbreak to spin_needbreak, make it use spin_is_contended to
> > > decouple it from the spinlock
On Thu, 2007-11-01 at 10:26 -0700, Paul Jackson wrote:
> Christoph wrote:
> > The library interface can set flags to modify behavior.
>
> A library such as libnuma can set them, yes, but not everyone uses
> libnuma. Basically everyone uses the standard C library, glibc, which
> has the system cal
On Wed, 2007-08-29 at 09:29 -0400, Daniel Drake wrote:
> Hi,
>
> I've spent some time trying to understand why swapoff is such a slow
> operation.
>
> My experiments show that when there is not much free physical memory,
> swapoff moves pages out of swap at a rate of approximately 5mb/sec. When
>
On Wed, 2007-08-08 at 10:36 -0700, Christoph Lameter wrote:
> On Wed, 8 Aug 2007, Mel Gorman wrote:
>
> > These are the range of performance losses/gains I found when running against
> > 2.6.23-rc1-mm2. The set and these machines are a mix of i386, x86_64 and
> > ppc64 both NUMA and non-NUMA.
> >
On Fri, 2007-07-27 at 10:42 +0200, Nick Piggin wrote:
> Hi,
>
> Just got a bit of time to take another look at the replicated pagecache
> patch. The nopage vs invalidate race and clear_page_dirty_for_io fixes
> gives me more confidence in the locking now; the new ->fault API makes
> MAP_SHARED wri
On Wed, 2007-08-08 at 22:44 +0100, Mel Gorman wrote:
> On (08/08/07 14:30), Lee Schermerhorn didst pronounce:
> > On Wed, 2007-08-08 at 10:36 -0700, Christoph Lameter wrote:
> > > On Wed, 8 Aug 2007, Mel Gorman wrote:
> > >
> > > > o Remove bind_zonelist
On Fri, 2007-07-27 at 10:42 +0200, Nick Piggin wrote:
> Hi,
>
> Just got a bit of time to take another look at the replicated pagecache
> patch. The nopage vs invalidate race and clear_page_dirty_for_io fixes
> gives me more confidence in the locking now; the new ->fault API makes
> MAP_SHARED wri
On Mon, 2007-07-30 at 05:16 +0200, Nick Piggin wrote:
> On Fri, Jul 27, 2007 at 10:30:47AM -0400, Lee Schermerhorn wrote:
> > On Fri, 2007-07-27 at 10:42 +0200, Nick Piggin wrote:
> > > Hi,
> > >
> > > Just got a bit of time to take another look at the replicat
On Sun, 2007-07-29 at 04:59 -0700, Paul Jackson wrote:
> Lee Schermerhorn (via Andrew) wrote:
> > +static inline void node_set_state(int node, enum node_states state)
> > +{
> > + __node_set(node, &node_states[state]);
> > +}
> > +
> > +static
On Wed, 2007-08-01 at 10:53 -0700, Martin Bligh wrote:
> Nick Piggin wrote:
> > On Tue, Jul 31, 2007 at 11:14:08AM +0200, Andi Kleen wrote:
> >> On Tuesday 31 July 2007 07:41, Nick Piggin wrote:
> >>
> >>> I haven't given this idea testing yet, but I just wanted to get some
> >>> opinions on it fir
uch a good idea
when ZONE_MOVABLE is populated?]
Signed-off-by: Lee Schermerhorn <[EMAIL PROTECTED]>
kernel/sysctl.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: Linux/kernel/sysctl.c
===
--- Linux.orig/ker
On Wed, 2007-08-01 at 15:52 -0700, Martin Bligh wrote:
> >> This topic seems to come up periodically every since we first introduced
> >> the NUMA scheduler, and every time we decide it's a bad idea. What's
> >> changed? What workloads does this improve (aside from some artificial
> >> benchmark li
On Thu, 2007-08-02 at 09:44 +0900, KAMEZAWA Hiroyuki wrote:
> On Wed, 01 Aug 2007 15:02:51 -0400
> Lee Schermerhorn <[EMAIL PROTECTED]> wrote:
> > [But, maybe reordering the zonelists is not such a good idea
> > when ZONE_MOVABLE is populated?]
> >
>
> It&#
l build, several povray tracing apps, IO tests,
sequential and random vm fault tests and a number of 'bin' tests that
simulate a half a dozen crazed monkeys pounding away at keyboards
entering surprisingly error-free commands. All of these loop until
stopped or the system hangs/crash
On Wed, 2007-08-08 at 16:25 -0400, Lee Schermerhorn wrote:
> On Fri, 2007-07-27 at 10:42 +0200, Nick Piggin wrote:
> > Hi,
> >
> > Just got a bit of time to take another look at the replicated pagecache
> > patch. The nopage vs invalidate race and clear_page_dirty_for
On Mon, 2007-08-13 at 09:43 +0200, Nick Piggin wrote:
> On Fri, Aug 10, 2007 at 05:08:18PM -0400, Lee Schermerhorn wrote:
> > On Wed, 2007-08-08 at 16:25 -0400, Lee Schermerhorn wrote:
> > > On Fri, 2007-07-27 at 10:42 +0200, Nick Piggin wrote:
> > > > Hi,
> >
On Mon, 2007-08-13 at 15:12 -0500, Serge E. Hallyn wrote:
> Quoting Dhaval Giani ([EMAIL PROTECTED]):
> > Hi,
> >
> > On mounting cpusets using containers, I have been hitting the following
> > bug.
> >
> >
> > ---[ cut here ]
> > kernel BUG at kernel/cpuset.c:331!
> > CONFI
On Tue, 2007-08-14 at 13:03 -0500, Serge E. Hallyn wrote:
> Quoting Lee Schermerhorn ([EMAIL PROTECTED]):
> > On Mon, 2007-08-13 at 15:12 -0500, Serge E. Hallyn wrote:
> > > Quoting Dhaval Giani ([EMAIL PROTECTED]):
> > > > Hi,
> > > >
> > >
On Tue, 2007-08-14 at 14:23 -0500, Serge E. Hallyn wrote:
> Quoting Lee Schermerhorn ([EMAIL PROTECTED]):
> > On Tue, 2007-08-14 at 13:03 -0500, Serge E. Hallyn wrote:
> > > Quoting Lee Schermerhorn ([EMAIL PROTECTED]):
> > > > On Mon, 2007-08-13 at 15:1
On Tue, 2007-08-14 at 15:49 -0500, Serge E. Hallyn wrote:
> Quoting Serge E. Hallyn ([EMAIL PROTECTED]):
> > Quoting Lee Schermerhorn ([EMAIL PROTECTED]):
> > > On Tue, 2007-08-14 at 13:03 -0500, Serge E. Hallyn wrote:
> > > > Quoting Lee Schermerhorn ([EMAIL PROTECTE
I thought I'd first make sure this is the right approach.
addressed in v2 --lts
Signed-off-by: Serge E. Hallyn <[EMAIL PROTECTED]>
Signed-off-by: Dhaval Giani <[EMAIL PROTECTED]>
Signed-off-by: Lee Schermerhorn <[EMAIL PROTECTED]>
mm/page_alloc.c |7 ---
1 file
On Tue, 2007-08-14 at 14:28 -0700, Christoph Lameter wrote:
> On Tue, 14 Aug 2007, Serge E. Hallyn wrote:
>
> > CONFIG_NODES_SHIFT was unset, so MAX_NUMNODES=1, so
> > node_state() and node_set_state() are dummies.
>
> Ok then you did not have a NUMA system configured. So its okay for the
> dumm
On Tue, 2007-08-14 at 14:56 -0700, Christoph Lameter wrote:
> On Tue, 14 Aug 2007, Lee Schermerhorn wrote:
>
> > > Ok then you did not have a NUMA system configured. So its okay for the
> > > dummies to ignore the stuff. CONFIG_NODES_SHIFT is a constant and does
>
On Wed, 2007-08-15 at 09:31 -0500, Serge E. Hallyn wrote:
> Quoting Lee Schermerhorn ([EMAIL PROTECTED]):
> > On Tue, 2007-08-14 at 14:56 -0700, Christoph Lameter wrote:
> > > On Tue, 14 Aug 2007, Lee Schermerhorn wrote:
> > >
> > > > > Ok then you did
On Wed, 2007-08-15 at 12:12 -0500, Serge E. Hallyn wrote:
> Quoting Paul Jackson ([EMAIL PROTECTED]):
> > Lee wrote:
> > > [altho' methinks CPUSET should select CONTAINERS rather than
> > > depend on it...]
> >
> > Good point -- what do you think, Paul Menage?
>
> Paul mentioned (http://www.spini
On Wed, 2007-08-15 at 22:22 +0530, Dhaval Giani wrote:
> Hi,
>
> On Wed, Aug 15, 2007 at 11:31:42AM -0500, Serge E. Hallyn wrote:
> > Quoting Lee Schermerhorn ([EMAIL PROTECTED]):
> > > On Wed, 2007-08-15 at 09:31 -0500, Serge E. Hallyn wrote:
> > > > Quotin
On Wed, 2007-08-15 at 13:36 -0700, Christoph Lameter wrote:
> On Wed, 15 Aug 2007, Lee Schermerhorn wrote:
>
> > > So its always true for node 0. The "bit" is set.
> >
> > The issue is with the N_*_MEMORY masks. They don't get initialized
> >
tions that could be broken down the road, resulting
in extra work for someone to debug. Unlikely, perhaps, but who
needs the aggravation...
Tested on i386 !NUMA by Dhaval Giani. Fixes cpuset BUG.
Signed-off-by: Lee Schermerhorn <[EMAIL PROTECTED]>
mm/page_alloc.c |9 -
1 file
Mel [anyone?]
Do you know what the plans are for your "onezonelist" patch series?
Are they going into -mm for, maybe, .25? Or have they been dropped.
I carry the last posting in my mempolicy tree--sometimes below my
patches; sometimes above. Our patches touch some of the same places in
mempo
On Thu, 2007-11-08 at 11:12 -0800, Christoph Lameter wrote:
> On Thu, 8 Nov 2007, Mel Gorman wrote:
>
> > On Tue, 2007-11-06 at 17:11 -0800, Christoph Lameter wrote:
> > > Slab defragmentation is mainly an issue if Linux is used as a fileserver
> >
> > Was hoping this would get renamed to SLUB Ta
On Fri, 2007-11-09 at 08:45 -0800, Nishanth Aravamudan wrote:
> On 09.11.2007 [16:14:55 +], Mel Gorman wrote:
> > On (09/11/07 07:45), Christoph Lameter didst pronounce:
> > > On Fri, 9 Nov 2007, Mel Gorman wrote:
> > >
> > > > struct page * fastcall
> > > > __alloc_pages(gfp_t gfp_mask, uns
1 - 100 of 147 matches
Mail list logo
