Messages in this thread | | | Date | Thu, 16 Apr 2009 21:00:02 +0900 (JST) | Subject | Re: [PATCH 3/9] bio-cgroup controller | From | Ryo Tsuruta <> |
| |
Hi Andrea and Kamezawa-san,
> > > +#ifdef CONFIG_CGROUP_BIO > > > +/* > > > + * use lower 16 bits for flags and reserve the rest for the bio-cgroup id > > > + */ > > > +#define BIO_CGROUP_ID_SHIFT (16) > > > +#define BIO_CGROUP_ID_BITS (8 * sizeof(unsigned long) - BIO_CGROUP_ID_SHIFT) > > > + > > > +static inline unsigned long page_cgroup_get_bio_id(struct page_cgroup *pc) > > > +{ > > > + return pc->flags >> BIO_CGROUP_ID_SHIFT; > > > +} > > > + > > > +static inline void page_cgroup_set_bio_id(struct page_cgroup *pc, > > > + unsigned long id) > > > +{ > > > + WARN_ON(id >= (1UL << BIO_CGROUP_ID_BITS)); > > > + pc->flags &= (1UL << BIO_CGROUP_ID_SHIFT) - 1; > > > + pc->flags |= (unsigned long)(id << BIO_CGROUP_ID_SHIFT); > > > +} > > > +#endif > > > + > > Ah, there is "Lock" bit in pc->flags and above "set" code does read-modify-write > > without lock_page_cgroup(). > > > > Could you use lock_page_cgroup() or cmpxchg ? (or using something magical technique ?) > > If I'm not wrong this should guarantee atomicity without using > lock_page_cgroup().
I'll consider carefully how is the best way to minimize the overhead as far as possible. First, I'll post the new bio-cgroup patches that use css_id as bio_cgroup_id soon.
Thanks, Ryo Tsuruta
| |