Re: [PATCH 3/3] HWPOISON: improve handling/reporting of memory error on dirty pagecache

[Andi Kleen]

> > That function uses a global lock. fdatawait is quite common. This will
> > likely cause performance problems in IO workloads.
> 
> OK, I should avoid it.

Maybe just RCU the hash table.
 
> > You need to get that lock out of the hot path somehow.
> > 
> > Probably better to try to put the data into a existing data structure,
> > or if you cannot do that you would need some way to localize the lock.
> 
> Yes, I have thought about adding some data like new pagecache tag or
> new members in struct address_space, but it makes the size of heavily
> used data structure larger so I'm not sure it's acceptable.
> And localizing the lock is worth trying, I think.

It's cheaper than a hash table lookup in the hot path.
 
> > Or at least make it conditional of hwpoison errors being around. 
> 
> I'll try to do your suggestions, but I'm not sure your point of the
> last one. Can you explain more about 'make it conditional' option?

The code should check some flag first that is only set when hwpoison
happened on the address space (or global, but that would mean that 
performance can go down globally when any error is around)

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/