Andy Gospodarek <[EMAIL PROTECTED]> wrote:
[...]
>My patch actually only uses a single workqueue for each bond (almost
>exactly like yours in-fact) with 4 different types of work that can be
>placed on it.
Well, what I was trying to say was that there are still multiple
independently sched
On 12/7/06, Jay Vosburgh <[EMAIL PROTECTED]> wrote:
I don't see a problem in starting with your patch; the end state
will be sufficiently different (e.g., the four workqueues would
ultimately be consolidated into one) that it's still a good testbed to
start with.
My patch actually only
Andy Gospodarek <[EMAIL PROTECTED]> wrote:
>On 12/4/06, Jay Vosburgh <[EMAIL PROTECTED]> wrote:
[...]
>> Appended is my working development patch for rearranging a bunch
>> of stuff in bonding. This is a work in progress, and is not likely to
>> be very stable. This largely reimplements
On 12/4/06, Jay Vosburgh <[EMAIL PROTECTED]> wrote:
Andy Gospodarek <[EMAIL PROTECTED]> wrote:
[...]
>> Let me see if I can dust off the extensive patch that does
>> change the locking model; I'll see if I can bring it up to the current
>> git and post it.
>>
>
>It would seem ideal if we
On 11/30/06, Jay Vosburgh <[EMAIL PROTECTED]> wrote:
Andy Gospodarek <[EMAIL PROTECTED]> wrote:
>The main purpose of this patch is to clean-up the bonding code so that
>several important operations are not done in the incorrect (softirq)
>context. Whenever a kernel is compiled with CONFIG_DEBUG_
Andy Gospodarek <[EMAIL PROTECTED]> wrote:
>The main purpose of this patch is to clean-up the bonding code so that
>several important operations are not done in the incorrect (softirq)
>context. Whenever a kernel is compiled with CONFIG_DEBUG_SPINLOCK_SLEEP
>all sorts of backtraces are spewed to t
The main purpose of this patch is to clean-up the bonding code so that
several important operations are not done in the incorrect (softirq)
context. Whenever a kernel is compiled with CONFIG_DEBUG_SPINLOCK_SLEEP
all sorts of backtraces are spewed to the log since might_sleep will
kindly remind us