[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architect
From: |
Eli Zaretskii |
Subject: |
bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture |
Date: |
Thu, 10 Nov 2016 19:24:31 +0200 |
> Cc: 24892@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 10 Nov 2016 08:59:11 -0800
>
> On 11/10/2016 08:13 AM, Eli Zaretskii wrote:
> > how can zero be a useful approximation of the memory footprint of a
> > running process?
>
> It's not, but memory-limit is not about memory footprint.
It is, in a way, although it only reports part of that footprint.
> > What does memory-limit return on your system?
>
> 47668, representing about 47 MiB. In contrast, (alist-get 'vsize
> (process-attributes (emacs-pid))) returns 807344, representing about 788
> MiB. So 0 is numerically closer to the "correct" answer.
"Numerically closer" doesn't mean "useful". Depending on what the
user wants, either result could be useful, but zero isn't.
> > I think we should have a function that does this in, say, simple.el,
> > under a name such as emacs-memory-size, and point to that in the
> > obsolescence note.
>
> Something like that could be done in a later patch. However, the notion
> "memory size" is vague and prone to misinterpretation, so any later
> patch should be done carefully. And I'm leery of defining a function
> that nobody is asking for - if nobody has cared for many years that
> memory-limit has been returning bogus values, then why do we need a
> function at all?
It only returned bogus results on some platforms.
FWIW, I'm frequently interested in the Emacs memory footprint, for
various reasons, so having a function in Emacs would be handy.
> OK, less-drastic patch attached.
Thanks, LGTM for master.
- bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture, (continued)
- bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture, Eli Zaretskii, 2016/11/07
- bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture, Paul Eggert, 2016/11/08
- bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture, Eli Zaretskii, 2016/11/08
- bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture, Paul Eggert, 2016/11/08
- bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture, Eli Zaretskii, 2016/11/08
- bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture, Paul Eggert, 2016/11/09
- bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture, Eli Zaretskii, 2016/11/09
- bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture, Paul Eggert, 2016/11/09
- bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture, Eli Zaretskii, 2016/11/10
- bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture, Paul Eggert, 2016/11/10
- bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture,
Eli Zaretskii <=
- bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture, Richard Stallman, 2016/11/09
- bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture, Paul Eggert, 2016/11/09
bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture, Ashish SHUKLA, 2016/11/08
- bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture, Paul Eggert, 2016/11/09
- bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture, Andreas Schwab, 2016/11/09
- bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture, Eli Zaretskii, 2016/11/09
- bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture, Paul Eggert, 2016/11/09
- bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture, Andreas Schwab, 2016/11/10
- bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture, Paul Eggert, 2016/11/10
- bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture, Andreas Schwab, 2016/11/10