Re: [rox-devel] CSystem: kernel-2.6 fix

[Ken H. <kh...@so...>]

Yeah, I reported this a while back but couldn't quite figure out the 'real answer'.  No one here seemed to know or care either so I dropped it.

One problem I have is that the bars in System appear to be trying to show overall memory per task, but the 3 items shown aren't guaranteed to add up to that goal.  I'm not sure what was intended originally so it is hard to figure out how to make it right.

Any ideas?  Should System's UI here be redesigned?

As I remember it, each task's info can only be accurate as resident/non-resident.  Or shared/non-shared.  But trying to combine resident and shared cannot be properly calculated.  There isn't enough information given.


Guido Schimmels wrote:
> I know the C version of System is no longer maintained in favour of the  
> python implementation. On the downside it introduces dependencies to  
> ctypes and libgtop. As I link libgtop in statically into a tiny 68k  
> resulting binary, CSystem doesn't introduce any runtime dependencies  
> for me. Which is why I still prefer it. Unfortunately kernel 2.6 API  
> changes broke it.
> 
> For some reason we get negative values on 2.6 kernels with
> task->rss - task->shared
> 
> Symptons:
> 
> - Continous gtk-critical messages on the console
> - the unshared bar comes and goes on mouse-over
> 
> I don't know a proper fix. So all I can offer is this naive work- 
> around, which makes System at least somewhat useable again:
> 
> --- procsys.c.orig    2004-03-13 02:25:36.626053056 +0200
> +++ procsys.c    2004-03-13 01:42:39.406849928 +0200
> @@ -205,7 +205,7 @@
> 
>         gtk_tree_store_set(tree, &new, 0, task->command,
>             1, (double) task->shared,
> -            2, (double) task->rss - task->shared,
> +            2, (double) abs(task->rss - task->shared),
>             3, (double) task->size - task->rss,
>             4, (gint64) task->pid,
>             5, state,
> 
> This fix obviously begs the question. I have. however, attached a  
> relevant bugzilla thread, explaining the changes in the kernel API and  
> how it has been applied to libgtop. Maybe that helps to fix it  properl
> y.

-- 

Ken Hayber (kh...@so...)
Huntington Beach, CA