On 02/20/2012 08:30 PM, Andrew Jones wrote:
>
>
> ----- Original Message -----
>> On Mon, Feb 20, 2012 at 11:44:25AM +0530, Raghavendra K T wrote:
>>> On 02/20/2012 10:46 AM, Jeremy Fitzhardinge wrote:
>>> [...]

Hi Drew,
Thanks for the reply

> Hi Raghavendra,

> sorry I didn't get around to starting this discussion myself when
> I first touched the issue. I also bumped into it when attempting
> to rebase pvticketlocks, so I pinged Gleb with the idea to split
> the header. As he's said again now though, he wasn't sure if jump
> labels were necessary in the pvticketlock implementation. In the
> meantime I got busy with other stuff, and didn't get a chance to
> continue/expand the discussion.
>
> I actually think we could consider both of the issues separately
> though.

Right.

  Should we split jump_label.h to make sure we can include
> it where it could otherwise get the cyclic dependencies due to
> workqueue.h? The only argument I can see against that is that
> jumplabels may change again, and then we may hit another issue,
> then again, etc., but handling them like this case by case isn't
> very clean.

Hmm..Handling the way it is handled by me sometime looks ugly to me.
The patch I have posted is only important set of changes. But for
complete yesconfig to work, it still would require change something like
below I am attaching, which (needs 24 file changes) makes it more ugly.
Only point is I can continue testing paravirt spinlock on tip.

Perhaps we need jump_label.h to define a "minimal
> jump label", and then we can create an "extended jump label",
> which has rate limiting and other capabilities.
>

I completely agree. seeing that, you have not started that, it seems
it's good idea for me to take a look at that option, (but may be at
slower pace considering some changes I require (TODO) for kvm paravirt
spinlock).

> Drew
>
>
--->8---
---