On 20 Nov, 2014, at 11:07 , Masao Uebayashi wrote:
> On Wed, Nov 19, 2014 at 2:49 PM, Dennis Ferguson
> wrote:
>> That's very true, but the code is only correct if the writes occur
>> in the order the C code has them written (i.e. tqe_next in the
>> new element is written before writing the tqe_
On 19 Nov, 2014, at 21:00 , Taylor R Campbell
wrote:
> Since most machines don't need any barrier here it would be extremely
> inefficient to add a membar_consumer() since that would make all machines
> pay for the idiosyncrasies unique to the DEC Alpha.
>
> We could invent a membar_datad
Looks good to me.
But you should test before commit. :)
On Wed, Nov 19, 2014 at 2:49 PM, Dennis Ferguson
wrote:
> That's very true, but the code is only correct if the writes occur
> in the order the C code has them written (i.e. tqe_next in the
> new element is written before writing the tqe_next of the existing
> list element to point at it). To ens
On Thu, Nov 20, 2014 at 11:51 AM, Masao Uebayashi wrote:
> On Thu, Nov 20, 2014 at 11:38 AM, Ryota Ozaki wrote:
>> Actually FreeBSD seems to have a callout for each interface. Even more
>> they killed the common if_watchdog facility and each driver has its own.
>
> What happens if many (e.g. 1,00
On Thu, Nov 20, 2014 at 11:38 AM, Ryota Ozaki wrote:
> Actually FreeBSD seems to have a callout for each interface. Even more
> they killed the common if_watchdog facility and each driver has its own.
What happens if many (e.g. 1,000) virtual ifs are present?
> Anyway here is a patch:
> http://w
On Wed, Nov 19, 2014 at 2:38 PM, Masao Uebayashi wrote:
> On Wed, Nov 19, 2014 at 11:24 AM, Ryota Ozaki wrote:
>> Weird :-/
>
> I don't think so. For fast paths to access data really fast, slow
> paths take a little way around (pre-allocation, etc). This is a fair
> trade-off. If you can achie
On Wed, Nov 19, 2014 at 10:00 PM, Taylor R Campbell
wrote:
>Date: Wed, 19 Nov 2014 17:11:18 +0800
>From: Dennis Ferguson
>
>On 19 Nov, 2014, at 01:53 , Taylor R Campbell
> wrote:
>> The one tricky detail is that after a reader has fetched the tqe_next
>> pointer, it must iss
Date: Wed, 19 Nov 2014 16:28:41 +0800
From: Dennis Ferguson
On 19 Nov, 2014, at 01:54 , Taylor R Campbell
wrote:
> What type pun is that? I don't see it.
I think this one:
#define TAILQ_LAST(head, headname) \
(*(((struct headname *)((head)->tqh_last))->tqh_last)
Date: Wed, 19 Nov 2014 17:11:18 +0800
From: Dennis Ferguson
On 19 Nov, 2014, at 01:53 , Taylor R Campbell
wrote:
> The one tricky detail is that after a reader has fetched the tqe_next
> pointer, it must issue a membar_consumer before dereferencing the
> pointer: otherwise the
On 19 Nov, 2014, at 01:53 , Taylor R Campbell
wrote:
> Date: Tue, 18 Nov 2014 23:13:34 +0900
> From: Masao Uebayashi
>
> In pserialize_perform(), context switches are made on all CPUs. After
> pserialize_perform(), all readers on all CPUs see the update data.
> The data old data ite
On 19 Nov, 2014, at 01:54 , Taylor R Campbell
wrote:
> Date: Wed, 19 Nov 2014 00:05:05 +0800
> From: Dennis Ferguson
>
> Also, the TAILQ macros depend on a type pun fairly similar to the one
> that did in the CIRCLEQ macros and hence have a lifetime which extends
> only to some futu
12 matches
Mail list logo
