Gregory Haskins wrote: > We can avoid dirtying a rq related cacheline with a simple check, so why not. > > Signed-off-by: Gregory Haskins <[email protected]> > --- > > 0 files changed, 0 insertions(+), 0 deletions(-) I think you wanted a patch here? - 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 the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: [PATCH 9/9] RT: Only dirty a cacheline if the priority is actually changing
- From: Gregory Haskins <[email protected]>
- Re: [PATCH 9/9] RT: Only dirty a cacheline if the priority is actually changing
- From: Steven Rostedt <[email protected]>
- Re: [PATCH 9/9] RT: Only dirty a cacheline if the priority is actually changing
- References:
- [PATCH 0/9] RT: RT-Overload/Sched enhancements v4
- From: Gregory Haskins <[email protected]>
- [PATCH 9/9] RT: Only dirty a cacheline if the priority is actually changing
- From: Gregory Haskins <[email protected]>
- [PATCH 0/9] RT: RT-Overload/Sched enhancements v4
- Prev by Date: Re: [GIT] NFS client fixes for 2.6.23++
- Next by Date: Re: [RFC] full suspend/resume support for i915 DRM driver
- Previous by thread: [PATCH 9/9] RT: Only dirty a cacheline if the priority is actually changing
- Next by thread: Re: [PATCH 9/9] RT: Only dirty a cacheline if the priority is actually changing
- Index(es):
 |