Re: [PATCH] [11/19] HWPOISON: Refactor truncate to allow direct truncating of page v2

Re: [PATCH] [11/19] HWPOISON: Refactor truncate to allow direct truncating of page v2

[Nick Piggin]

On Wed, Aug 05, 2009 at 04:10:01PM +0200, Andi Kleen wrote:
> > I haven't brought up the caller at this point, but IIRC you had
> > the page locked and mapping confirmed at this point anyway so
> > it would never be an error for your code.
> > 
> > Probably it would be nice to just force callers to verify the page.
> > Normally IMO it is much nicer and clearer to do it at the time the
> > page gets locked, unless there is good reason otherwise.
> 
> Ok. I think I'll just keep it as it is for now.
> 
> The only reason I added the error code was to make truncate_inode_page
> fit into .error_remove_page, but then latter I did another wrapper
> so it could be removed again. But it won't hurt to have it either.

OK, it's more of a cleanup/nit.

One question I had for the others (Andrew? other mm guys?) what is the
feelings of merging this feature? Leaving aside exact implementation
and just considering the high level design and cost/benefit. Last time
there were some people objecting, so I wonder the situation now? So
does anybody need more convincing? :)

Also I will just cc linux-arch. It would be interesting to know whether
powerpc, ia64, or s390 or others would be interested to use this feature?

Thanks,
Nick

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] [11/19] HWPOISON: Refactor truncate to allow direct truncating of page v2

[Nick Piggin]

On Wed, Aug 05, 2009 at 04:10:01PM +0200, Andi Kleen wrote:
> > I haven't brought up the caller at this point, but IIRC you had
> > the page locked and mapping confirmed at this point anyway so
> > it would never be an error for your code.
> > 
> > Probably it would be nice to just force callers to verify the page.
> > Normally IMO it is much nicer and clearer to do it at the time the
> > page gets locked, unless there is good reason otherwise.
> 
> Ok. I think I'll just keep it as it is for now.
> 
> The only reason I added the error code was to make truncate_inode_page
> fit into .error_remove_page, but then latter I did another wrapper
> so it could be removed again. But it won't hurt to have it either.

OK, it's more of a cleanup/nit.

One question I had for the others (Andrew? other mm guys?) what is the
feelings of merging this feature? Leaving aside exact implementation
and just considering the high level design and cost/benefit. Last time
there were some people objecting, so I wonder the situation now? So
does anybody need more convincing? :)

Also I will just cc linux-arch. It would be interesting to know whether
powerpc, ia64, or s390 or others would be interested to use this feature?

Thanks,
Nick

Re: [PATCH] [11/19] HWPOISON: Refactor truncate to allow direct truncating of page v2

[Andi Kleen]

> One question I had for the others (Andrew? other mm guys?) what is the
> feelings of merging this feature? Leaving aside exact implementation
> and just considering the high level design and cost/benefit. Last time
> there were some people objecting, so I wonder the situation now? So
> does anybody need more convincing? :)

The main objection last time was that it was a bit too late in the 
release schedule.

I can't remember anyone really questioning the basic feature itself.

> Also I will just cc linux-arch. It would be interesting to know whether
> powerpc, ia64, or s390 or others would be interested to use this feature?

ia64 is interested (but no code so far) I talked to DaveM and he seems to be 
interested for sparc too.  I would expect other server architectures to 
eventually use it as they get around to writing the necessary architecture 
specific glue.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: [PATCH] [11/19] HWPOISON: Refactor truncate to allow direct truncating of page v2

[Nick Piggin]

On Wed, Aug 05, 2009 at 04:41:12PM +0200, Andi Kleen wrote:
> > One question I had for the others (Andrew? other mm guys?) what is the
> > feelings of merging this feature? Leaving aside exact implementation
> > and just considering the high level design and cost/benefit. Last time
> > there were some people objecting, so I wonder the situation now? So
> > does anybody need more convincing? :)
> 
> The main objection last time was that it was a bit too late in the 
> release schedule.
> 
> I can't remember anyone really questioning the basic feature itself.

I can't exactly remember. Maybe it was in a thread with Alan and/or
Arjan ;) I don't think the feature itself was questioned as much as
cost/benefit. Maybe I was wrong...

I just want to see everyone is happy with the basic idea ;)


> > Also I will just cc linux-arch. It would be interesting to know whether
> > powerpc, ia64, or s390 or others would be interested to use this feature?
> 
> ia64 is interested (but no code so far) I talked to DaveM and he seems to be 
> interested for sparc too.  I would expect other server architectures to 
> eventually use it as they get around to writing the necessary architecture 
> specific glue.

Re: [PATCH] [11/19] HWPOISON: Refactor truncate to allow direct truncating of page v2

[Matthew Wilcox]

On Wed, Aug 05, 2009 at 04:41:12PM +0200, Andi Kleen wrote:
> > One question I had for the others (Andrew? other mm guys?) what is the
> > feelings of merging this feature? Leaving aside exact implementation
> > and just considering the high level design and cost/benefit. Last time
> > there were some people objecting, so I wonder the situation now? So
> > does anybody need more convincing? :)
> 
> The main objection last time was that it was a bit too late in the 
> release schedule.
> 
> I can't remember anyone really questioning the basic feature itself.
> 
> > Also I will just cc linux-arch. It would be interesting to know whether
> > powerpc, ia64, or s390 or others would be interested to use this feature?
> 
> ia64 is interested (but no code so far) I talked to DaveM and he seems to be 
> interested for sparc too.  I would expect other server architectures to 
> eventually use it as they get around to writing the necessary architecture 
> specific glue.

parisc could certainly implement this.  Don't know if there's interest.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: [PATCH] [11/19] HWPOISON: Refactor truncate to allow direct truncating of page v2

[Martin Schwidefsky]

On Wed, 5 Aug 2009 16:16:42 +0200
Nick Piggin <npiggin@suse.de> wrote:

> On Wed, Aug 05, 2009 at 04:10:01PM +0200, Andi Kleen wrote:
> > > I haven't brought up the caller at this point, but IIRC you had
> > > the page locked and mapping confirmed at this point anyway so
> > > it would never be an error for your code.
> > > 
> > > Probably it would be nice to just force callers to verify the page.
> > > Normally IMO it is much nicer and clearer to do it at the time the
> > > page gets locked, unless there is good reason otherwise.
> > 
> > Ok. I think I'll just keep it as it is for now.
> > 
> > The only reason I added the error code was to make truncate_inode_page
> > fit into .error_remove_page, but then latter I did another wrapper
> > so it could be removed again. But it won't hurt to have it either.
> 
> OK, it's more of a cleanup/nit.
> 
> One question I had for the others (Andrew? other mm guys?) what is the
> feelings of merging this feature? Leaving aside exact implementation
> and just considering the high level design and cost/benefit. Last time
> there were some people objecting, so I wonder the situation now? So
> does anybody need more convincing? :)
> 
> Also I will just cc linux-arch. It would be interesting to know whether
> powerpc, ia64, or s390 or others would be interested to use this feature?

This is not relevant for s390, as current machines do transparent memory
sparing if a memory module goes bad. Really old machines reported bad
memory to the OS by means of a machine check (storage error uncorrected
and storage error corrected). I have never seen this happen, the level
below the OS deals with these errors for us.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: [PATCH] [11/19] HWPOISON: Refactor truncate to allow direct truncating of page v2

[Andi Kleen]

> This is not relevant for s390, as current machines do transparent memory
> sparing if a memory module goes bad. Really old machines reported bad
> memory to the OS by means of a machine check (storage error uncorrected
> and storage error corrected). I have never seen this happen, the level
> below the OS deals with these errors for us.

Ok fine. It's for the poorer cousins then who can't afford memory mirroring.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.