On Thu, May 10, 2007 at 03:39:36PM -0400, Mathieu Desnoyers wrote:
> * Christoph Hellwig ([EMAIL PROTECTED]) wrote:
> > On Thu, May 03, 2007 at 01:16:46PM -0400, Mathieu Desnoyers wrote:
> > > > kprobes does this kind of synchronization internally, so the marker
> > > > wrapper should probabl aswel
* Christoph Hellwig ([EMAIL PROTECTED]) wrote:
> On Thu, May 03, 2007 at 01:16:46PM -0400, Mathieu Desnoyers wrote:
> > > kprobes does this kind of synchronization internally, so the marker
> > > wrapper should probabl aswell.
> > >
> >
> > The problem appears on heavily loaded systems. Doing 50
Hugh Dickins wrote:
On Thu, 10 May 2007, Nick Piggin wrote:
The filesystem (or page cache) allows pages beyond i_size to come
in there? That wasn't a problem before, was it? But now it is?
The filesystem still doesn't, but if i_size is updated after the page
is returned, we can have a probl
On Thu, 10 May 2007, Nick Piggin wrote:
> >
> > The filesystem (or page cache) allows pages beyond i_size to come
> > in there? That wasn't a problem before, was it? But now it is?
>
> The filesystem still doesn't, but if i_size is updated after the page
> is returned, we can have a problem tha
Hugh Dickins wrote:
On Wed, 9 May 2007, Nick Piggin wrote:
Hugh Dickins wrote:
On Wed, 2 May 2007, Nick Piggin wrote:
But I'm pretty sure (to use your words!) regular truncate was not racy
before: I believe Andrea's sequence count was handling that case fine,
without a second unmap_mapping
On Wed, 9 May 2007, Nick Piggin wrote:
> Hugh Dickins wrote:
> > On Wed, 2 May 2007, Nick Piggin wrote:
>
> > > >But I'm pretty sure (to use your words!) regular truncate was not racy
> > > >before: I believe Andrea's sequence count was handling that case fine,
> > > >without a second unmap_mappin
Hugh Dickins wrote:
On Wed, 2 May 2007, Nick Piggin wrote:
But I'm pretty sure (to use your words!) regular truncate was not racy
before: I believe Andrea's sequence count was handling that case fine,
without a second unmap_mapping_range.
OK, I think you're right. I _think_ it should also be
On Fri, 2007-05-04 at 19:23 +1000, Nick Piggin wrote:
> These ops could also be put to use in bit spinlocks, buffer lock, and
> probably a few other places too.
Ok, the performance hit seems to be under control (especially with the
bigger benchmark showing actual improvements).
There's a little
On Mon, Apr 30, 2007 at 04:20:07PM -0700, Andrew Morton wrote:
...
> git-unionfs.patch
>
> Does this have a future?
Yes! There are many active users who use our unioning functionality.
Namespace unification consists of several major parts:
1) Duplicate elimination: This can be handled in the V
Sorry for late response. I went on a vacation in last week.
And I'm in the mountain of a ton of unread mail now
> > Mel's moveable-zone work.
>
> These patches are what creates ZONE_MOVABLE. The last 6 patches should be
> collapsed into a single patch:
>
> handle-kernelcore=-generic
>
Nick Piggin wrote:
Nick Piggin wrote:
Christoph Hellwig wrote:
Is that every fork/exec or just under certain cicumstances?
A 5% regression on every fork/exec is not acceptable.
Well after patch2, G5 fork is 3% and exec is 1%, I'd say the P4
numbers will be improved as well with that pat
Nick Piggin wrote:
Christoph Hellwig wrote:
Is that every fork/exec or just under certain cicumstances?
A 5% regression on every fork/exec is not acceptable.
Well after patch2, G5 fork is 3% and exec is 1%, I'd say the P4
numbers will be improved as well with that patch. Then if we have
spe
Andrew Morton wrote:
On Thu, 03 May 2007 11:32:23 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
void fastcall unlock_page(struct page *page)
{
+ VM_BUG_ON(!PageLocked(page));
smp_mb__before_clear_bit();
- if (!TestClearPageLocked(page))
- BUG();
- smp_mb__after
On Fri, 4 May 2007, Benjamin Herrenschmidt wrote:
> > The SLUB allocator relies on struct page fields first_page and slab,
> > overwritten by ptl when SPLIT_PTLOCK: so the SLUB allocator cannot then
> > be used for the lowest level of pagetable pages. This was obstructing
> > SLUB on PowerPC, whi
On Thu, 2007-05-03 at 22:04 +0100, Hugh Dickins wrote:
> On Thu, 3 May 2007, Hugh Dickins wrote:
> >
> > Seems we're all wrong in thinking Christoph's Kconfiggery worked
> > as intended: maybe it just works some of the time. I'm not going
> > to hazard a guess as to how to fix it up, will resume
On Thu, 3 May 2007, Christoph Lameter wrote:
>
> There are SLUB patches pending (not in rc7-mm2 as far as I can recall)
> that reduce the default page order sizes to head off this issue. The
> defaults were initially too large (and they still default to large
> for testing if Mel's Antifrag work
On Thu, 3 May 2007, Hugh Dickins wrote:
> On Thu, 3 May 2007, Hugh Dickins wrote:
> >
> > Seems we're all wrong in thinking Christoph's Kconfiggery worked
> > as intended: maybe it just works some of the time. I'm not going
> > to hazard a guess as to how to fix it up, will resume looking at
> >
On Thu, 3 May 2007, Hugh Dickins wrote:
>
> Seems we're all wrong in thinking Christoph's Kconfiggery worked
> as intended: maybe it just works some of the time. I'm not going
> to hazard a guess as to how to fix it up, will resume looking at
> the powerpc's quicklist potential later.
Here's the
On Thu, May 03, 2007 at 01:16:46PM -0400, Mathieu Desnoyers wrote:
> > kprobes does this kind of synchronization internally, so the marker
> > wrapper should probabl aswell.
> >
>
> The problem appears on heavily loaded systems. Doing 50
> synchronize_sched() calls in a row can take up to a few s
Here is the reworked patch, except a comment :
* Christoph Hellwig ([EMAIL PROTECTED]) wrote:
> > +void blk_probe_disconnect(void)
> > +{
> > + uint8_t i;
> > +
> > + for (i = 0; i < NUM_PROBES; i++) {
> > + marker_remove_probe(probe_array[i].name);
> > + }
> > + synchronize_sche
On Thu, 03 May 2007 11:32:23 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
> void fastcall unlock_page(struct page *page)
> {
> + VM_BUG_ON(!PageLocked(page));
> smp_mb__before_clear_bit();
> - if (!TestClearPageLocked(page))
> - BUG();
> - smp_mb__after_clear_bit();
H...There are a gazillion configs to choose from. It works fine with
cell_defconfig. If I switch to 2 processors I can enable SLUB if I switch
to 4 I cannot.
I saw some other config weirdness like being unable to set SMP if SLOB is
enabled with some configs. This should not work and does not
On Thu, 3 May 2007, William Lee Irwin III wrote:
> I've seen this crash in flush_old_exec() before. ISTR it being due to
> slub vs. pagetable alignment or something on that order.
>From from other discussion regarding SLAB: It may be necessary for
powerpc to set the default alignment to 8 bytes
On Thu, May 03, 2007 at 11:04:15AM -0400, Mathieu Desnoyers wrote:
> - blk_add_trace_rq(q, rq, BLK_TA_INSERT);
> + MARK(blk_request_insert, "%p %p", q, rq);
I don't really like the shouting MARK name very much. Can we have
a less-generic, less shouting name, e.g. trace_marker? The aboe w
* Andrew Morton ([EMAIL PROTECTED]) wrote:
> > Although some, like Christoph and myself, think that it would benefit to
> > the kernel community to have a common infrastructure for more than just
> > markers (meaning common serialization and buffering mechanism), it does
> > not change the fact tha
Hi Andi,
This plan makes sense. I will split the "patched in enabled/disable
flags" part into a separate piece (good idea!) and then submit the LTTng
core to Andrew. Christoph's has a good point about wanting a usable
infrastructure to go ini. Regarding your plan, I must argue that
blktrace is not
* Christoph Hellwig ([EMAIL PROTECTED]) wrote:
> On Wed, May 02, 2007 at 07:11:04PM -0400, Mathieu Desnoyers wrote:
> > My statement was probably not clear enough. The actual marker code is
> > useful as-is without any further kernel patching required : SystemTAP is
> > an example where they use ex
Hugh Dickins wrote:
On Thu, 3 May 2007, Nick Piggin wrote:
@@ -568,6 +570,11 @@ __lock_page (diff -p would tell us!)
{
DEFINE_WAIT_BIT(wait, &page->flags, PG_locked);
+ set_bit(PG_waiters, &page->flags);
+ if (unlikely(!TestSetPageLocked(page))) {
What happens if another cpu is c
On Thu, 3 May 2007, Nick Piggin wrote:
> >>@@ -568,6 +570,11 @@ __lock_page (diff -p would tell us!)
> > > {
> > > DEFINE_WAIT_BIT(wait, &page->flags, PG_locked);
> > >
> > >+ set_bit(PG_waiters, &page->flags);
> > >+ if (unlikely(!TestSetPageLocked(page))) {
> >
> > What happens if another cpu
Christoph Hellwig wrote:
On Thu, May 03, 2007 at 11:32:23AM +1000, Nick Piggin wrote:
The attached patch gets performance up a bit by avoiding some
barriers and some cachelines:
G5
pagefault fork exec
2.6.21 1.49-1.51 164.6-170.8 741.8-760.3
+patch 1.71-1.73 175.2-
Hugh Dickins wrote:
On Thu, 3 May 2007, Nick Piggin wrote:
The problem is that lock/unlock_page is expensive on powerpc, and
if we improve that, we improve more than just the fault handler...
The attached patch gets performance up a bit by avoiding some
barriers and some cachelines:
There's
On Thu, 3 May 2007, Nick Piggin wrote:
>
> The problem is that lock/unlock_page is expensive on powerpc, and
> if we improve that, we improve more than just the fault handler...
>
> The attached patch gets performance up a bit by avoiding some
> barriers and some cachelines:
There's a strong whi
On Thu, May 03, 2007 at 11:32:23AM +1000, Nick Piggin wrote:
> The attached patch gets performance up a bit by avoiding some
> barriers and some cachelines:
>
> G5
> pagefault fork exec
> 2.6.21 1.49-1.51 164.6-170.8 741.8-760.3
> +patch 1.71-1.73 175.2-180.8 780.5-
> If we are looking at current "potential users" that are already in
> mainline, we could change blktrace to make it use the markers.
Ok, but do it step by step:
- split out useful pieces like the "patched in enable/disable flags"
and submit them separate with an example user or two
[I got a cou
On Wed, May 02, 2007 at 11:46:40PM +0200, Tilman Schmidt wrote:
> Am 02.05.2007 19:49 schrieb Andi Kleen:
> > And also I think when something is merged it should have some users in tree.
>
> Isn't that a circular dependency?
The normal mode of operation is to merge the initial users and the
subs
On Thu, 3 May 2007, Andrew Morton wrote:
> On Thu, 3 May 2007 09:46:32 +0100 (BST) Hugh Dickins <[EMAIL PROTECTED]>
> wrote:
> > On Thu, 3 May 2007, Andrew Morton wrote:
> > > On Wed, 2 May 2007 10:25:47 -0700 (PDT) Christoph Lameter <[EMAIL
> > > PROTECTED]> wrote:
> > >
> > > > +config ARCH_US
On Thu, 3 May 2007 09:46:32 +0100 (BST) Hugh Dickins <[EMAIL PROTECTED]> wrote:
> On Thu, 3 May 2007, Andrew Morton wrote:
> > On Wed, 2 May 2007 10:25:47 -0700 (PDT) Christoph Lameter <[EMAIL
> > PROTECTED]> wrote:
> >
> > > +config ARCH_USES_SLAB_PAGE_STRUCT
> > > + bool
> > > + default y
> >
On Thu, 3 May 2007, Andrew Morton wrote:
> On Wed, 2 May 2007 10:25:47 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]>
> wrote:
>
> > +config ARCH_USES_SLAB_PAGE_STRUCT
> > + bool
> > + default y
> > + depends on SPLIT_PTLOCK_CPUS <= NR_CPUS
> > +
>
> That all seems to work as intended.
On Thu, May 03, 2007 at 01:15:15AM -0700, Andrew Morton wrote:
> That all seems to work as intended.
> However with NR_CPUS=8 SPLIT_PTLOCK_CPUS=4, enabling SLUB=y crashes the
> machine early in boot.
> Too early for netconsole, no serial console. Wedges up uselessly with
> CONFIG_XMON=n, does my
On Wed, 2 May 2007 10:25:47 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> On Wed, 2 May 2007, Hugh Dickins wrote:
>
> > I presume the answer is just to extend your quicklist work to
> > powerpc's lowest level of pagetables. The only other architecture
> > which is using kmem_cache
On Wed, May 02, 2007 at 04:36:27PM -0400, Mathieu Desnoyers wrote:
> The idea is the following : either we integrate the infrastructure for
> instrumentation / data serialization / buffer management / extraction of
> data to user space in multiple different steps, which makes code review
> easier f
On Wed, May 02, 2007 at 01:53:36PM -0700, Andrew Morton wrote:
> In which case we have:
>
> atomich-add-atomic64-cmpxchg-xchg-and-add_unless-to-alpha.patch
> atomich-complete-atomic_long-operations-in-asm-generic.patch
> atomich-i386-type-safety-fix.patch
> atomich-add-atomic64-cmpxchg-xchg-and-ad
On Wed, May 02, 2007 at 07:11:04PM -0400, Mathieu Desnoyers wrote:
> My statement was probably not clear enough. The actual marker code is
> useful as-is without any further kernel patching required : SystemTAP is
> an example where they use external modules to load probes that can
> connect either
Hugh Dickins wrote:
On Wed, 2 May 2007, Nick Piggin wrote:
[snip]
More on-topic, since you suggest doing more within vmtruncate_range
than the filesystem: no, I'm afraid that's misdesigned, and I want
to move almost all of it into the filesystem ->truncate_range.
Because, if what vmtruncate_r
Hugh Dickins wrote:
On Wed, 2 May 2007, Nick Piggin wrote:
Yes, but IIRC I put that in because there was another check in
SLES9 that I actually couldn't put in, but used this one instead
because it also caught the bug we saw.
...
This was actually a rare corruption that is also in 2.6.21, and
On Wed, 2 May 2007 19:11:04 -0400
Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> > I didn't know that this was the plan.
> >
> > The problem I have with this is that once we've merged one part, we're
> > committed to merging the other parts even though we haven't seen them yet.
> >
> > What happ
* Andrew Morton ([EMAIL PROTECTED]) wrote:
> On Wed, 2 May 2007 16:36:27 -0400
> Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
>
> > * Christoph Hellwig ([EMAIL PROTECTED]) wrote:
> > > On Wed, May 02, 2007 at 09:47:07AM -0700, Andrew Morton wrote:
> > > > > That doesn't constitute using it.
> > >
Am 02.05.2007 19:49 schrieb Andi Kleen:
> And also I think when something is merged it should have some users in tree.
Isn't that a circular dependency?
--
Tilman Schmidt E-Mail: [EMAIL PROTECTED]
Bonn, Germany
- Undetected errors are handled as if no error occurred. (IB
On Wed, 2 May 2007 16:36:27 -0400
Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> * Christoph Hellwig ([EMAIL PROTECTED]) wrote:
> > On Wed, May 02, 2007 at 09:47:07AM -0700, Andrew Morton wrote:
> > > > That doesn't constitute using it.
> > >
> > > Andi, there was a huge amount of discussion abou
* Christoph Hellwig ([EMAIL PROTECTED]) wrote:
> On Wed, May 02, 2007 at 09:47:07AM -0700, Andrew Morton wrote:
> > > That doesn't constitute using it.
> >
> > Andi, there was a huge amount of discussion about all this in September last
> > year (subjects: *markers* and *LTTng*). The outcome of al
On Wed, 2 May 2007, Sam Ravnborg wrote:
> To facilitate this do NOT introduce CONFIG_SLAB until we decide
> that SLUB are default. In this way we can make CONFIG_SLUB be default
> and people will not continue with CONFIG_SLAB because they had it in their
> config already.
We already have CONFIG_S
On Wed, May 02, 2007 at 12:42:54PM -0700, Christoph Lameter wrote:
> On Wed, 2 May 2007, Andrew Morton wrote:
>
> > > At some point I dream that SLUB could become the default but I thought
> > > this would take at least 6 month or so. If want to force this now then I
> > > will certainly have so
On Wed, 2 May 2007, Pekka Enberg wrote:
> And then there's patches such as kmemleak which would need to target
> all three. Plus it doesn't really make sense for users to select
> between three competiting implementations. Please don't take away our
> high hopes of getting rid of mm/slab.c Christo
On Wed, 2 May 2007, Andrew Morton wrote:
> > At some point I dream that SLUB could become the default but I thought
> > this would take at least 6 month or so. If want to force this now then I
> > will certainly have some busy weeks ahead.
>
> s/dream/promise/ ;)
>
> Six months sounds reasonab
On Wed, 2 May 2007, Pekka Enberg wrote:
> On 5/2/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > I am the one who has to maintain SLAB and SLUB it seems and I have been
> > dealing with the trio SLAB, SLOB and SLUB for awhile now. Its okay and it
> > will be much easier once the cleanups are
On 5/2/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
Owww... You throw my roadmap out of the window and may create too
high expectations of SLUB.
Me too!
On 5/2/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
I am the one who has to maintain SLAB and SLUB it seems and I have been
dealing
On Wed, 2 May 2007 10:03:50 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Wed, 2 May 2007, Hugh Dickins wrote:
>
> > But if Linus' tree is to be better than a warehouse to avoid
> > awkward merges, I still think we want it to default to on for
> > all the architectures, and for mo
On Wed, 2 May 2007, Andrew Morton wrote:
> n, we don't want competing slab allocators, please. We should get slub
> working well on all architectures then remove slab completely. Having to
> maintain both slab.c and slub.c would be awful.
Owww... You throw my roadmap out of the window and m
On Wed, 2 May 2007, Siddha, Suresh B wrote:
> I have been looking into "slub" recently to avoid some of the NUMA alien
> cache issues that we were encountering on the regular slab.
Yes that is also our main concern.
> I am having some stability issues with slub on an ia64 NUMA platform and
> did
On Wed, 2 May 2007 11:39:20 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Wed, 2 May 2007, Hugh Dickins wrote:
>
> > I'm astonished and impressed, both with Kconfig and your use of it:
>
> Thanks!
>
> > I'd much rather be testing a quicklist patch:
> > I'd better give that a try
On Wed, May 02, 2007 at 05:54:53AM -0700, Hugh Dickins wrote:
> On Tue, 1 May 2007, Andrew Morton wrote:
> > So on balance, given that we _do_ expect slub to have a future, I'm
> > inclined to crash ahead with it. The worst that can happen will be a later
> > rm mm/slub.c which would be pretty sim
On Wed, 2 May 2007, Andrew Morton wrote:
> > This is a sensitive piece of the kernel as you say and we better allow the
> > running of two allocator for some time to make sure that it behaves in all
> > load situations. The design is fundamentally different so its performance
> > characteristic
On Wed, 2 May 2007 11:28:26 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Wed, 2 May 2007, Hugh Dickins wrote:
>
> > On Wed, 2 May 2007, Christoph Lameter wrote:
> > >
> > > But these are arch specific problems. We could use
> > > ARCH_USES_SLAB_PAGE_STRUCT to disable SLUB on th
On Wed, 2 May 2007, Hugh Dickins wrote:
> I'm astonished and impressed, both with Kconfig and your use of it:
Thanks!
> I'd much rather be testing a quicklist patch:
> I'd better give that a try.
Great. But I certainly do not mind people use SLAB. I do not think that
one approach should be the
On Wed, 2 May 2007, Christoph Lameter wrote:
> On Wed, 2 May 2007, Hugh Dickins wrote:
>
> > I presume the answer is just to extend your quicklist work to
> > powerpc's lowest level of pagetables. The only other architecture
> > which is using kmem_cache for them is arm26, which has
> > "#error S
On Wed, 2 May 2007, Hugh Dickins wrote:
> On Wed, 2 May 2007, Christoph Lameter wrote:
> >
> > But these are arch specific problems. We could use
> > ARCH_USES_SLAB_PAGE_STRUCT to disable SLUB on these platforms.
>
> As a quick hack, sure. But every ARCH_USES_SLAB_PAGE_STRUCT
> diminishes the
On Wed, 2 May 2007, Christoph Lameter wrote:
>
> But these are arch specific problems. We could use
> ARCH_USES_SLAB_PAGE_STRUCT to disable SLUB on these platforms.
As a quick hack, sure. But every ARCH_USES_SLAB_PAGE_STRUCT
diminishes the testing SLUB will get. If the idea is that we're
going
On Wed, May 02, 2007 at 09:47:07AM -0700, Andrew Morton wrote:
> On Wed, 2 May 2007 12:44:13 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > > It is currently used as an instrumentation infrastructure for the LTTng
> > > tracer at IBM, Google, Autodesk, Sony, MontaVista and deployed in
> > > Win
On Wed, May 02, 2007 at 09:47:07AM -0700, Andrew Morton wrote:
> > That doesn't constitute using it.
>
> Andi, there was a huge amount of discussion about all this in September last
> year (subjects: *markers* and *LTTng*). The outcome of all that was, I
> believe, that the kernel should have a st
* Andi Kleen ([EMAIL PROTECTED]) wrote:
> > It is currently used as an instrumentation infrastructure for the LTTng
> > tracer at IBM, Google, Autodesk, Sony, MontaVista and deployed in
> > WindRiver products. The SystemTAP project also plan to use this type of
> > infrastructure to trace sites h
On Wed, 2 May 2007, Hugh Dickins wrote:
> I presume the answer is just to extend your quicklist work to
> powerpc's lowest level of pagetables. The only other architecture
> which is using kmem_cache for them is arm26, which has
> "#error SMP is not supported", so won't be giving this problem.
I
On Wed, 2 May 2007, Hugh Dickins wrote:
> But if Linus' tree is to be better than a warehouse to avoid
> awkward merges, I still think we want it to default to on for
> all the architectures, and for most if not all -rcs.
At some point I dream that SLUB could become the default but I thought
thi
On Wed, 2 May 2007, Hugh Dickins wrote:
> > Why would we need to go back to SLAB if we have not switched to SLUB? SLUB
> > is marked experimental and not the default.
>
> I said above that I thought SLUB ought to be defaulted to on throughout
> the -rcs: if we don't do that, we're not going to l
On Wed, 2 May 2007 12:44:13 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote:
> > It is currently used as an instrumentation infrastructure for the LTTng
> > tracer at IBM, Google, Autodesk, Sony, MontaVista and deployed in
> > WindRiver products. The SystemTAP project also plan to use this type of
> >
Andi Kleen <[EMAIL PROTECTED]> writes:
> [...] The SystemTAP project also plan to use this type of
> > infrastructure to trace sites hard to instrument. The Linux Kernel
> > Markers has the support of Frank C. Eigler, author of their current
> > marker alternative [...]
>
> All of the above don'
Chris Wright wrote:
> * Greg KH ([EMAIL PROTECTED]) wrote:
>> And is this really a problem? The whole goal of the -stable tree was to
>> accomidate the users who relied on kernel.org kernels, and wanted
>> bugfixes and security updates. It was not for new features or new
>> hardware support.
>>
>
On Wed, 2 May 2007, Nick Piggin wrote:
> Hugh Dickins wrote:
> >
> > But I was quite disappointed when
> > mm-fix-fault-vs-invalidate-race-for-linear-mappings-fix.patch
> > appeared, putting double unmap_mapping_range calls in. Certainly
> > you were wrong to take the one out, but a pity to end u
On Wed, 2 May 2007, Nick Piggin wrote:
>
> Yes, but IIRC I put that in because there was another check in
> SLES9 that I actually couldn't put in, but used this one instead
> because it also caught the bug we saw.
>...
> This was actually a rare corruption that is also in 2.6.21, and
> as few rma
On Tue, 1 May 2007, Andrew Morton wrote:
>
> Given the current state and the current rate of development I'd expect slub
> to have reached the level of completion which you're describing around -rc2
> or -rc3. I think we'd be pretty safe making that assumption.
Its developer does show signs of b
On Tue, 1 May 2007, Christoph Lameter wrote:
> On Tue, 1 May 2007, Hugh Dickins wrote:
>
> > Yes, to me it does. If it could be defaulted to on throughout the
> > -rcs, on every architecture, then I'd say that's "finishing work";
> > and we'd be safe knowing we could go back to slab in a hurry if
> It is currently used as an instrumentation infrastructure for the LTTng
> tracer at IBM, Google, Autodesk, Sony, MontaVista and deployed in
> WindRiver products. The SystemTAP project also plan to use this type of
> infrastructure to trace sites hard to instrument. The Linux Kernel
> Markers has
On Wed, May 02, 2007 at 10:31:10AM +1000, Rusty Russell wrote:
> On Tue, 2007-05-01 at 14:17 +0200, Andi Kleen wrote:
> > Andrew Morton <[EMAIL PROTECTED]> writes:
> > > Will merge the rustyvisor.
> >
> > IMHO the user code still doesn't belong into Documentation.
> > Also it needs another review
Nick Piggin wrote:
Hugh Dickins wrote:
On Tue, 1 May 2007, Nick Piggin wrote:
There were concerns that we could do this more cheaply, but I think it
is important to start with a base that is simple and more likely to
be correct and build on that. My testing didn't show any obvious
problems
Hugh Dickins wrote:
On Tue, 1 May 2007, Nick Piggin wrote:
There were concerns that we could do this more cheaply, but I think it
is important to start with a base that is simple and more likely to
be correct and build on that. My testing didn't show any obvious
problems with performance.
I
Hugh Dickins wrote:
On Mon, 30 Apr 2007, Andrew Morton wrote:
...
mm-more-rmap-checking.patch
...
Misc MM things. Will merge.
Would Nick mind very much if I ask you to drop this one?
You did CC me ages ago, but I've only just run across it.
It's a small matter, but I'd prefer it dropped f
* Greg KH ([EMAIL PROTECTED]) wrote:
> And is this really a problem? The whole goal of the -stable tree was to
> accomidate the users who relied on kernel.org kernels, and wanted
> bugfixes and security updates. It was not for new features or new
> hardware support.
>
> If people feel we should
On Tue, May 01, 2007 at 05:40:33PM +0100, Alan Cox wrote:
> > > But distros can easily add the device id to their kernel if needed, it
> > > isn't something that the -stable tree shoud be accepting. Otherwise, we
> > > will be swamped with those types of patches...
> > >
> >
> > Oh sure, leave t
On Tue, 2007-05-01 at 14:17 +0200, Andi Kleen wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
> > Will merge the rustyvisor.
>
> IMHO the user code still doesn't belong into Documentation.
> Also it needs another review round I guess. And some beta testing by
> more people.
Like any piece of c
Hi Andi,
* Andi Kleen ([EMAIL PROTECTED]) wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
>
> > Static markers. Will merge.
> There don't seem to be any users of this. How do you know it hasn't
> already bitrotted?
>
See the detailed explanation at :
http://kernel.org/pub/linux/kernel/pe
On Tue, 1 May 2007 13:46:26 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Tue, 1 May 2007, Andrew Morton wrote:
>
> > otoh I could do some frantic patch mangling and make it easier to carry
> > slub out-of-tree, but do we gain much from that?
>
> Then we may loose all the slab AP
On Tue, 1 May 2007, Hugh Dickins wrote:
> Yes, to me it does. If it could be defaulted to on throughout the
> -rcs, on every architecture, then I'd say that's "finishing work";
> and we'd be safe knowing we could go back to slab in a hurry if
> needed. But it hasn't reached that stage yet, I thi
On Tue, 1 May 2007, Andrew Morton wrote:
> otoh I could do some frantic patch mangling and make it easier to carry
> slub out-of-tree, but do we gain much from that?
Then we may loose all the slab API cleanups? Yuck. I really do not want
redo those
-
To unsubscribe from this list: send the
On Tue, 1 May 2007 21:19:09 +0100 (BST)
Hugh Dickins <[EMAIL PROTECTED]> wrote:
> On Tue, 1 May 2007, Andrew Morton wrote:
> > On Tue, 1 May 2007 19:10:29 +0100 (BST)
> > Hugh Dickins <[EMAIL PROTECTED]> wrote:
> >
> > > > Most of the rest of slub. Will merge it all.
> > >
> > > Merging slub al
On Tue, 1 May 2007, Andrew Morton wrote:
> On Tue, 1 May 2007 19:10:29 +0100 (BST)
> Hugh Dickins <[EMAIL PROTECTED]> wrote:
>
> > > Most of the rest of slub. Will merge it all.
> >
> > Merging slub already? I'm surprised.
>
> My thinking here is "does slub have a future".
> I think the answer
On Tue, 1 May 2007 19:10:29 +0100 (BST)
Hugh Dickins <[EMAIL PROTECTED]> wrote:
> > Most of the rest of slub. Will merge it all.
>
> Merging slub already? I'm surprised.
My thinking here is "does slub have a future". I think the answer is
"yes", so we're reasonably safe getting it into mainli
On Tue, 1 May 2007, Nick Piggin wrote:
> Andrew Morton wrote:
>
> > mm-simplify-filemap_nopage.patch
> > mm-fix-fault-vs-invalidate-race-for-linear-mappings.patch
> > mm-merge-populate-and-nopage-into-fault-fixes-nonlinear.patch
> > mm-merge-nopfn-into-fault.patch
> > convert-hugetlbfs-to-use
On Tue, 1 May 2007, Hugh Dickins wrote:
> > Most of the rest of slub. Will merge it all.
>
> Merging slub already? I'm surprised. That's a very key piece of
> infrastructure, and I doubt it's had the exposure it needs yet.
Its not the default. Its just an alternative like SLOB. It will take s
On Tue, 01 May 2007 14:02:41 +0100 Andy Whitcroft <[EMAIL PROTECTED]> wrote:
> I have some primitive stats patches which we have used performance
> testing. Perhaps those could be brought up to date to provide better
> visibility into lumpy's operation. Again this would be a separate patch.
Fee
On Tue, 1 May 2007 11:16:51 +0100 [EMAIL PROTECTED] (Mel Gorman) wrote:
>
OK, I did all the reorganisation which you recommended.
> Ok. It is getting reviewed by Christoph and I'm going through the TODO items
> it yielded. Andy has also been regularly reviewing them which is probably
> why they
On Tue, 1 May 2007, Christoph Lameter wrote:
> On Tue, 1 May 2007, Mel Gorman wrote:
>
>>anti-fragmentation-switch-over-to-pfn_valid_within.patch
>>
>> These patches are the grouping pages by mobility patches. They get tested
>> every time someone boots the machine from the perspective that th
1 - 100 of 141 matches
Mail list logo
