unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
* Questions about proced
@ 2024-04-06  9:57 Rahguzar
  2024-04-06 17:47 ` Eli Zaretskii
  0 siblings, 1 reply; 8+ messages in thread
From: Rahguzar @ 2024-04-06  9:57 UTC (permalink / raw)
  To: help-gnu-emacs

I have a question about proced:

1) The pmem construct in proced corresponds to the percentage of memory used
by a process. However the total memory used for this calculation
includes swap. Is it possible to limit this to just RAM?

2) The pcpu construct displays the percentage of cpu used by a process.
However it seems like it uses a very long interval to calculate this
percentage. So often processes which are basically idle now show up at
the top when sorting the processes by pcpu and I can see the cpu used by
them decaying slowly. Is it possible to use a shorter interval for pcpu?

Thanks,
Rahguzar



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Questions about proced
  2024-04-06  9:57 Rahguzar
@ 2024-04-06 17:47 ` Eli Zaretskii
  0 siblings, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2024-04-06 17:47 UTC (permalink / raw)
  To: help-gnu-emacs

> From: Rahguzar <rahguzar@zohomail.eu>
> Date: Sat, 06 Apr 2024 11:57:09 +0200
> 
> I have a question about proced:
> 
> 1) The pmem construct in proced corresponds to the percentage of memory used
> by a process. However the total memory used for this calculation
> includes swap. Is it possible to limit this to just RAM?

I'm not sure I understand: you do have rss in the attributes, and I
presume that the amount of physical RAM in the system is well known,
so why is it a problem?

> 2) The pcpu construct displays the percentage of cpu used by a process.
> However it seems like it uses a very long interval to calculate this
> percentage. So often processes which are basically idle now show up at
> the top when sorting the processes by pcpu and I can see the cpu used by
> them decaying slowly. Is it possible to use a shorter interval for pcpu?

AFAIK, this is calculated by the OS, not by Emacs.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Questions about proced
@ 2024-04-07 15:33 Rahguzar
  2024-04-07 16:09 ` Eli Zaretskii
  0 siblings, 1 reply; 8+ messages in thread
From: Rahguzar @ 2024-04-07 15:33 UTC (permalink / raw)
  To: eliz; +Cc: help-gnu-emacs

Hi Eli,

> I'm not sure I understand: you do have rss in the attributes, and I
> presume that the amount of physical RAM in the system is well known,
> so why is it a problem?

It is a minor problem but I actually don't understand how proced is
calculating the percentage. If I compare the percentage memory value
from proced with that of top I see that top show a value 4 times that of
proced. Before noticing this I though it was due to proced including
swap but the amount swap is half the amount of ram so I would have
expected the factor to be 1.5. Other programs also show values very
similar to top. The problem is that if I don't remember this fact, I
don't catch the high memory usage.

> > 2) The pcpu construct displays the percentage of cpu used by a process.
> > However it seems like it uses a very long interval to calculate this
> > percentage. So often processes which are basically idle now show up at
> > the top when sorting the processes by pcpu and I can see the cpu used by
> > them decaying slowly. Is it possible to use a shorter interval for pcpu?

> AFAIK, this is calculated by the OS, not by Emacs.

Comparing with top, I notice that value is top changes much more quickly
compared to proced and better reflects the current load. The amount of
total cpu time used by a process is identical between top and proced so
I had assumed that they differed by how the calculated the current load.

Thanks,
Rahguzar



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Questions about proced
  2024-04-07 15:33 Rahguzar
@ 2024-04-07 16:09 ` Eli Zaretskii
  0 siblings, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2024-04-07 16:09 UTC (permalink / raw)
  To: help-gnu-emacs

> From: Rahguzar <rahguzar@zohomail.eu>
> Cc: help-gnu-emacs@gnu.org
> Date: Sun, 07 Apr 2024 17:33:50 +0200
> 
> Hi Eli,
> 
> > I'm not sure I understand: you do have rss in the attributes, and I
> > presume that the amount of physical RAM in the system is well known,
> > so why is it a problem?
> 
> It is a minor problem but I actually don't understand how proced is
> calculating the percentage. If I compare the percentage memory value
> from proced with that of top I see that top show a value 4 times that of
> proced. Before noticing this I though it was due to proced including
> swap but the amount swap is half the amount of ram so I would have
> expected the factor to be 1.5. Other programs also show values very
> similar to top. The problem is that if I don't remember this fact, I
> don't catch the high memory usage.

You have the sources (in sysdep.c) of what Emacs does, so you can just
look there, and then consult the various system documentation.  AFAIR,
the %Mem column should show the percentage of the physical RAM that
the process's RSS (resident set) takes.  That's what I see on 2
different systems, one MS-Windows, the other GNU/Linux.  On the latter
I compared with 'top', and it shows the same value.  So I don't think
I understand why you see something different.

> > > 2) The pcpu construct displays the percentage of cpu used by a process.
> > > However it seems like it uses a very long interval to calculate this
> > > percentage. So often processes which are basically idle now show up at
> > > the top when sorting the processes by pcpu and I can see the cpu used by
> > > them decaying slowly. Is it possible to use a shorter interval for pcpu?
> 
> > AFAIK, this is calculated by the OS, not by Emacs.
> 
> Comparing with top, I notice that value is top changes much more quickly
> compared to proced and better reflects the current load. The amount of
> total cpu time used by a process is identical between top and proced so
> I had assumed that they differed by how the calculated the current load.

You need to tell more details, like which process you are looking at
in the list (better not be the Emacs process which shows the Proced
display, for obvious reasons), whether you enabled auto-update in
Proced and with what update interval, etc. etc.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Questions about proced
@ 2024-07-23 19:26 Rahguzar
  2024-07-24 16:34 ` Eli Zaretskii
  0 siblings, 1 reply; 8+ messages in thread
From: Rahguzar @ 2024-07-23 19:26 UTC (permalink / raw)
  To: help-gnu-emacs

Hi Eli,

[Sending this message again because I accidentally sent it just to Eli.
(Sorry about that)]

> > It is a minor problem but I actually don't understand how proced is
> > calculating the percentage. If I compare the percentage memory value
> > from proced with that of top I see that top show a value 4 times that of
> > proced. Before noticing this I though it was due to proced including
> > swap but the amount swap is half the amount of ram so I would have
> > expected the factor to be 1.5. Other programs also show values very
> > similar to top. The problem is that if I don't remember this fact, I
> > don't catch the high memory usage.

> You have the sources (in sysdep.c) of what Emacs does, so you can just
> look there, and then consult the various system documentation.  AFAIR,
> the %Mem column should show the percentage of the physical RAM that
> the process's RSS (resident set) takes.  That's what I see on 2
> different systems, one MS-Windows, the other GNU/Linux.  On the latter
> I compared with 'top', and it shows the same value.  So I don't think
> I understand why you see something different.

Sorry for coming back to this so late. I am using a GNU/Linux but with a
kernal that has a 16k page size. I think that might be the problem?

I don't understand C at all but I looked at the sysdep.c as weird math.
What stands out is line 3741:

	  pmem = 4.0 * 100 * rss / procfs_get_total_memory ();

The 4.0 is what makes me suspicious but it is just a hunch without any
understanding.

Thanks,
Rahguzar



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Questions about proced
       [not found] ` <867cdb82rq.fsf@gnu.org>
@ 2024-07-24 16:31   ` Rahguzar
  0 siblings, 0 replies; 8+ messages in thread
From: Rahguzar @ 2024-07-24 16:31 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: help-gnu-emacs

Hi Eli,

[Adding the mailing list again since I accidentally forgot it last
time.]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Rahguzar <rahguzar@zohomail.eu>
>> Date: Tue, 23 Jul 2024 21:22:25 +0200
>> 
>> > You have the sources (in sysdep.c) of what Emacs does, so you can just
>> > look there, and then consult the various system documentation.  AFAIR,
>> > the %Mem column should show the percentage of the physical RAM that
>> > the process's RSS (resident set) takes.  That's what I see on 2
>> > different systems, one MS-Windows, the other GNU/Linux.  On the latter
>> > I compared with 'top', and it shows the same value.  So I don't think
>> > I understand why you see something different.
>> 
>> Sorry for coming back to this so late. I am using a GNU/Linux but with a
>> kernal that has a 16k page size. I think that might be the problem?
>> 
>> I don't understand C at all but I looked at the sysdep.c as weird math.
>> What stands out is line 3741:
>> 
>> 	  pmem = 4.0 * 100 * rss / procfs_get_total_memory ();
>> 
>> The 4.0 is what makes me suspicious but it is just a hunch without any
>> understanding.
>
> Like I said: the values I see are consistent with 'top', so I think
> whoever wrote that code knew what they were doing.  And note that
> values of 'rss' are multiplied by 4 everywhere they are used.  I think
> the reason is clear: the RSS value is given in units of pages, and
> each page is 4KB, so to convert that into KB units, you must multiply
> by 4.

Sorry, I wasn't clear enough but I wanted to say that one my system the
each page is 16KB and not 4KB so the multiplication should be by 16 and
not 4. This is why for me the value for percentage memory shown by top
is 4 times that show by proced.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Questions about proced
  2024-07-23 19:26 Rahguzar
@ 2024-07-24 16:34 ` Eli Zaretskii
  0 siblings, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2024-07-24 16:34 UTC (permalink / raw)
  To: help-gnu-emacs

> From: Rahguzar <rahguzar@zohomail.eu>
> Date: Tue, 23 Jul 2024 21:26:28 +0200
> 
> > You have the sources (in sysdep.c) of what Emacs does, so you can just
> > look there, and then consult the various system documentation.  AFAIR,
> > the %Mem column should show the percentage of the physical RAM that
> > the process's RSS (resident set) takes.  That's what I see on 2
> > different systems, one MS-Windows, the other GNU/Linux.  On the latter
> > I compared with 'top', and it shows the same value.  So I don't think
> > I understand why you see something different.
> 
> Sorry for coming back to this so late. I am using a GNU/Linux but with a
> kernal that has a 16k page size. I think that might be the problem?
> 
> I don't understand C at all but I looked at the sysdep.c as weird math.
> What stands out is line 3741:
> 
> 	  pmem = 4.0 * 100 * rss / procfs_get_total_memory ();
> 
> The 4.0 is what makes me suspicious but it is just a hunch without any
> understanding.

If there are systems there with 16KB pages, and /proc reports RSS for
them in 16KB pages units and not 4KB page units, then we'd need to
modify sysdep.c to multiply by the system's page size instead.

Suggest to report this with all the details as a bug, since here is
not a good place to discuss this stuff.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Questions about proced
@ 2024-07-24 17:41 Rahguzar
  0 siblings, 0 replies; 8+ messages in thread
From: Rahguzar @ 2024-07-24 17:41 UTC (permalink / raw)
  To: eliz; +Cc: help-gnu-emacs

Hi Eli,

> If there are systems there with 16KB pages, and /proc reports RSS for
> them in 16KB pages units and not 4KB page units, then we'd need to
> modify sysdep.c to multiply by the system's page size instead.

> Suggest to report this with all the details as a bug, since here is
> not a good place to discuss this stuff.

I have filed bug#72278 for this.

Thanks,
Rahguzar



^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2024-07-24 17:41 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <87ed7joqvi.fsf@zohomail.eu>
     [not found] ` <867cdb82rq.fsf@gnu.org>
2024-07-24 16:31   ` Questions about proced Rahguzar
2024-07-24 17:41 Rahguzar
  -- strict thread matches above, loose matches on Subject: below --
2024-07-23 19:26 Rahguzar
2024-07-24 16:34 ` Eli Zaretskii
2024-04-07 15:33 Rahguzar
2024-04-07 16:09 ` Eli Zaretskii
2024-04-06  9:57 Rahguzar
2024-04-06 17:47 ` Eli Zaretskii

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).