[Toybox] [PATCH] memeater: consume a given amount of memory.

[enh]

On Wed, Jan 24, 2024 at 11:56 PM Rob Landley <rob at landley.net> wrote:

> On 1/24/24 15:47, enh via Toybox wrote:
> > feel free to push back that "this is too Android-specific"...
>
> It's no sillier than devmem.
>
> You can't malloc more than a long so I'm switching the type to unsigned
> long and
> atolx_range(val, 0, ULONG_MAX).
>

d'oh! (sorry, i'm such an LP64 bigot these days... i genuinely forget that
LP32 exists most of the time.)


> Should the mlock() be optional? (Maybe -m? Or for backwards compatibility
> keep
> it the default and -M to _not_ lock? Dirtying isn't optional because
> without
> that the malloc just updates a couple pointers and maybe extends a
> mapping.)
>

dunno... the specific Android copy i set out to remove doesn't have the
mlock(), but spent most of its initial checkin comment effectively saying
"this tool doesn't do quite what you want because it doesn't mlock()", so
it does seem like it should be there and -- because i'm told this is mainly
used by non-engineers under instruction -- probably on by default. (that's
why the original daemonizes itself, which is why i was looking at
xvdaemon() yesterday, but it offended my sensibilities not to just say `adb
shell nohup memeater` until/unless that's proven to be too error-prone or
whatever.)


> Since this is just dirtying pages do you object to += 4096 in the loop? Or
> do
> you want the ascending numbers over the memory? Or maybe a -f option for
> fast to
> do that and once again leave the default?
>

no, when i asked the heap guys if they had any comments, the only thing
they said was "why are you wasting time touching more than one byte per
page?", and my only answer was "because the toybox guy will probably prefer
the shorter code, which is this". like i said in the checkin comment,
until/unless proven insufficient, i don't think there's any reason but
cargo cult for the current behavior.


> Sigh, almost all toybox command line numbers understand unit suffixes. I
> wince
> documenting it here the same as repeatedly explaining "-" in file
> arguments,
> although you know your audience better than I do...
>

heh, that was actually my compromise between _my_ preference for nothing
(even for this tool, i assume they'll be told `adb shell memeater 512m` or
whatever, not left to their own devices) and the toy i copied from
[truncate.c] actually listing out a subset of the prefixes and what numbers
they correspond to (!).


> Anyway, quick stab at what cleaning it up might look like attached...
>

lgtm, though i'd probably say "YAGNI" to the -f flag and just always have
the fast behavior? gkaiser (already cc:ed) will be along shortly to tell us
if that doesn't work for him for some reason :-)


> > it's possible that
> > a better answer to the Android Go folks' "i wish we always had this on
> the
> > device" is to just always build it for the device as-is (or if we really
> want to
> > hide it away, just bung it in the ghost of toolbox).
>
> I keep meaning to re-examine the ghost of toolbox, but all I actually
> remember
> is a couple christmases back I wrote the first half of a mkvfat and then
> went
> down the rathole of "you don't get to NOT support 12 bit fat, and the
> cutoff for
> switching over is NOT DOCUMENTED, and then 32 bit fat is just weird, and
> while
> I'm here I should look into mtools, and wouldn't it be nice to somehow
> genericize that the way zless and zgrep and zdiff work..."
>

toolbox is probably best left as-is. we moved getprop/setprop back into
toolbox (so they could reuse some OS libraries that aren't exposed in the
NDK), and start/stop don't make any sense outside Android. that only really
leaves getevent which -- as long as we have kernel headers and you don't --
is slightly better off in toolbox because we can just auto-generate the
list from <linux/input.h> based on the current kernel headers, without ever
having to remember to manually update.


> Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20240125/771ee5b9/attachment.htm>