rv's techblog: some kind of blog

Earlier this morning I integrated changes into ON to decouple the lbolt and lbolt64 variables from clock() as part of the Tickless Kernel project. Here's the heads-up message that followed. Please let me know if you run into any issues or have questions about this change. A follow up post will describe the changes in more detail.

---

With the integration of

PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling
6860030 tickless clock requires a clock() decoupled lbolt / lbolt64

the lbolt and lbolt64 variables have been removed from the system, and the service historically provided by them replaced with the ddi_get_lbolt(9F) and ddi_get_lbolt64(9F) routines. These two functions should be used from now on to get a clock tick based time reference.

This push also introduces the cv_reltimedwait(9F) and cv_reltimedwait_sig(9F) DDI interfaces, which are analogous to the existing cv_timedwait(9F) and cv_timedwait_sig(9F), but take a relative timeout argument instead of an absolute one, and a time resolution argument to specify how accurately the timeout must expire (if it can be anticipated or deferred by the given time unit). These two new interfaces help reduce redundant uses of lbolt in various timed wait consumers. The condvar(9F) man page is being updated with the details, there's an updated version available on our project page[1].

We have, and will continue to work with ISVs and RPE to identify third party modules that improperly reference the lbolt variables and will need to be updated for this CR. We've also identified a handful of references to them in non-ON consolidations and have worked with the appropriate teams to fix them, with ge(7D) being the only outstanding known case (see 6878074).

Please send questions to tickless-dev@opensolaris.org, bugs to solaris/kernel/time and myself. More information on our project page[1] and our PSARC case[2].

[1] http://hub.opensolaris.org/bin/view/Project+tickless/
[2] http://arc.opensolaris.org/caselog/PSARC/2009/396

---

Thanks to everyone who contributed to this project. On to the next one!

Quick post on this, I'm pretty sure more people run into the same problem.. Usually the first thing I do after opening a new gnome-terminal is resizing so it doesn't overlap over others or vice-versa. Or if I have a big screen, or know that I'll need really long terminals (or tall ones) and so on.. Anyway, resizing all the time becomes kinda annoying, so I've added the following option to the gnome-panel icon for opening a new terminal:

gnome-terminal --geometry=80x52

Last week I populated the ptop-gtk repository, which holds a Gtk based interface for PowerTOP I've been developing over the last couple of months on my spare time. This new interface is enabled with the -G command line option, and it accepts all the existing options.

The motivation for the new interface is quite simple: increase the density of information displayed to the user. The current curses based interface is very limiting as far as that goes - not to mention a pita to maintain. Yes, it looks pretty, but looks aren't everything ;). I personally think we can take a few generally simple steps with various tools to enhance user experience.

The first tab simply shows what you already get with the current interface, allowing more information than the latter. The second tab displays moving area graphs for idle and frequency states, and a graph for the event report.

A couple of screenshots:

This is still in early development, I've been pushing it along as time allows. I'm writing a Gtk widget for periodic graphs, which is extended by another widget for DTrace based graphs. These widgets allow a very simple plug and play into DTrace consumers, just instantiate one, point the it to the data and it will do the job.

There a number of simple bugs that need to be fixed, but it's a relatively good start. I don't know when it will be ready for putback into snv, like I said, it needs work and it's not a very high priority at the moment. On the same subject, I'm not sure Gtk should be a dependency for ON builds, maybe the right place for this is in another consolidation. I don't know yet.

As always, questions/comments/suggestions are more than welcome.

Enjoy !

Eu ja modifiquei o layout deste blog algumas vezes e as informações sobre o licenciamento sempre acabam se perdendo no processo. Dessa vez resolvi simplificar um pouco as coisas e simplesmente posta-las.

Todo o conteúdo em Portugues deste blog esta licenciado sob a Creative Commons Attribution-Noncommercial-Share Alike 2.5 Brazil License. Isso significa que não é permitido o uso comercial do conteúdo presente neste blog sem minha permissão, e que voce pode usar, distribuir e modificar desde que compartilhe sob a mesma licenca e que de créditos aos autores.

I've changed this blog's layout a few times since I started it, and usually the licensing information is lost somewhere in the process. Time time, I'm simply posting it.

So for what is worth, everything I've written here in English is under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License. This means you can't use any of the content for commercial use without my authorization, and you're free to use, distribute and modify it as long as you share it in the same way and provide credit.

The San Francisco OpenSolaris User Group is meeting next Monday (the 27th) at a new location, and starting to hold technical talks. Here's the lineup for this one:

• OpenSolaris.org Overview (Content/OGB/BootCamp Summary) (Michelle Olson)
• Installing OSOL on laptop (dual-boot/Vxm/VirtualBox) (Luc Suryo)
• OpenSolaris and Power Management (Rafael Vanoni)
• How SongBird is put together--for Dummies (Steve Lau)

A couple of months ago I proposed that we start having technical talks and promoting the meetings in different channels. Between all members, I'm sure we can make a reasonable amount of noise around the Bay Area. Anyway, I sent invitations to the SFLUG and JUG (thanks to the leaders of both groups for spreading the word), so hopefully we'll be able to keep this up and grow the group meeting by meeting.

If you're in the area next week, we're meeting at Outspark, on 660 3rd Street San Francisco, 3rd floor Suite #302, near the Borders bookstore. The tech talks should be around 10-15 minutes each, lightning talk style. We're going for drinks and food afterwards.

Thanks to Luc for hosting the meeting.

Ah! If you plan on attending, please rsvp @ our MeetUp page.