linux-kernel - Re: schedule (wait

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ada8waev3pi.fsf@roland-alpha.cisco.com>
Date:	Sat, 27 Feb 2010 12:11:37 -0800
From:	Roland Dreier <rdreier@...co.com>
To:	Rafał Miłecki <zajec5@...il.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: schedule (wait_event) vs. while

 > In radeon engine reclocking code I need to do some calculations and
 > then wait for VBLANK interrupt. Right after VBLANK interrupt will
 > happen I need to reclock ASAP.
 > 
 > Interrupts are received by another context and I need some quite fast
 > synchronization.
 > 
 > 1) Schedule solution:
 > reclocking() {
 >   calculations();
 >   radeon->vblank_sync = 0;
 >   wait_event_timeout(radeon->wq, radeon->vblank_sync, timeout);
 >   reclock();
 > }
 > i-handler() { radeon->vblank_sync = 1; }

What does reclock() involve?  Is there any reason you can't do it in the
interrupt handler?  (quite possibly it needs to sleep or something)

If you can do it in the interrupt handler, then your reclocking()
function could do the calculations, stash the result somewhere, and set
a flag that tells the interrupt handler to do the reclock().  Then you
could use a completion to have reclocking() wait until the reclock() was
actually done (the latency of that completion doesn't matter, since
you're not doing any actual work after the completion).

If you do need to wait for process context, then one possibility would
be to do reclocking() from a high-priority kernel thread.  Then the wake
up latency should be low (but maybe not low enough).  Or you could
convert the interrupt handler to use the new threaded interrupt support,
to get into a process context as fast as possible.

If you reall need to busy-wait, then

 > reclocking() {
 >   calculations();
 >   del_timer(radeon->fake_vblank);
 >   radeon->vblank_sync = 0;
 >   mod_timer(radeon->fake_vblank, 10ms);
 >   while(!radeon->vblank_sync);
 >   reclock();
 > }
 > i-handler() { radeon->vblank_sync = 1; }
 > fake-handler() { radeon->vblank_sync = 1; }

There's no need for the fake_vblank timer -- just keep track of the time
when you start busy-waiting and then exit the loop when 10ms passes.

 - R.
-- 
Roland Dreier  <rolandd@...co.com>
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/