netdev
[Top] [All Lists]

Re: [timers] net/core/*

To: andrewm@xxxxxxxxxx (Andrew Morton)
Subject: Re: [timers] net/core/*
From: kuznet@xxxxxxxxxxxxx
Date: Wed, 31 May 2000 23:03:20 +0400 (MSK DST)
Cc: netdev@xxxxxxxxxxx
In-reply-to: <39352AB3.7C609B8C@uow.edu.au> from "Andrew Morton" at May 31, 0 10:13:27 pm
Sender: owner-netdev@xxxxxxxxxxx
Hello!

> // NOW hits spin_trylock().  It succeeds.  dst_gc_timer is added a
> second time.

That's why del_timer was made before add_timer, it was not redundant yet. 8)

Certainly, add_timer should be converted to mod_timer and del_timer's
are deleted. It will be cleaner.


> If del_timer_async() returns non-zero then we KNOW that
> the timer was deleted and we KNOW that it hasn't run
> and we KNOW that it isn't running now.  So that's a
> reference count to the timer and we can safely do
> the neigh_release().

Exactly!

Also, we know that nobody but currently executed code needs
or knows anything about this object, so that it will be destroyed
by neigh_release().



> BTW:
> 
> asmlinkage void do_softirq()
> {
>       ...
> restart:
>       ...
>                 if ((active &= mask) != 0)
>                         goto retry;
>       ...
> retry:
>         goto restart;
> }
> 
> Doesn't need the double-goto.

It is consequence of too careful reading intel and alpha programmer's
guides. 8) All of them require to help static branch prediction
and not to jump forward in the most frequent path. It looks silly, when done
in C, but gcc has no means to do this in different way.

Alexey

<Prev in Thread] Current Thread [Next in Thread>