I don't think so, because the timestamp is when prinkt is called, not when
the content is actually printed out, and printk will not block.
Ronghua
On Sun, 29 Jun 2003, Matti Aarnio wrote:
> On Sun, Jun 29, 2003 at 10:37:12AM -0400, Ronghua Zhang wrote:
> > Hi,
> > I came to a situation that requires to send multiple TCP packets (one
> > for each connection) from a kernel thread as soon as possible. The
> > following is the skeleton of my code:
>
> I should say this is a heissenbug ... one which happens because
> you are observing it with printk().
>
> > kernel_thread()
> > {
> > foreach sk in (alive connections){
> > tp = &(sk->tp_pinfo.af_tcp);
> >
> > skb = alloc_skb(xxx, GFP_ATOMIC);
> > /* build TCP header */
> > tcp_build_and_update_options(.....);
> > tp->af_specific->send_check(sk, th, skb->len, skb);
> >
> > tp->af_specific->queue_xmit(skb);
> > printk("packet send out for sk %p, at %lu\n", sk, jiffies);
> > }
> > }
> >
> > the output is always like this:
> > packet send out for sk 1 at 1000
> > packet send out for sk 2 at 1001
> > packet send out for sk 3 at 1002
> > ...
> >
> > It looks like this kernel thread get rescheduled after it has sent out 1
> > packet. But why? each iteration certainly does not need 10ms, why it get
> > rescheduled? Is it because af_specific->queue_xmit() is blocking
> > operation? but I notice that tcp_transmit_skb() also call it, and
> > tcp_transmit_skb() should not call any blockalbe operation. I try to
> > increase its priority or change its schedule policy,but has no effect
> > at all. Any suggestion is appreciated! This is really urgent.
> >
> >
> > Ronghua
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
