Hello list,
Inspired by recent, unnecessarily combative discussion on the list, I
thought I'd try restart this conversation anew:
Is it possible to either add a reclaimable field the total memory line
of `systemctl status` output?
Or perhaps a separate line like Memory-Reclaimable: ?
Is
Am 28.09.20 um 19:32 schrieb Dave Howorth:
>> the far slower copy from the list-server is silently purged by
>> intention to avoid receive ever ymessage twice on mailing lists where
>> people can't handle a MUA
>
> Well then, it's not Benjamin breaking the threading, it's you :P
> You need to
On Mon, 28 Sep 2020 16:39:05 +0200
Reindl Harald wrote:
> Am 28.09.20 um 16:34 schrieb Dave Howorth:
> > On Mon, 28 Sep 2020 14:10:38 +0200
> > Reindl Harald wrote:
> >> can you stop "reply-all" and breaking threads when respond to
> >> lists?
> >
> > I can't answer for the reply-all, that
Am 28.09.20 um 18:33 schrieb Lennart Poettering:
> On Mo, 28.09.20 14:22, Reindl Harald (h.rei...@thelounge.net) wrote:
>
>> honestly: do you realize that i know very well how the memory management
>> of Linux works and that it's pretty fine but not part of the topic at all?
>
> Reindl, did
Hi,
There are a bunch of sandboxing options that I am trying to enable but I got no
effects when I am setting them. Below are the options that I am trying to set,
but I can't seem to turn them on.
LockPersonality=true
MemoryDenyWriteExecute=true
RestrictRealtime=true
RestrictSUIDSGID=true
On Mo, 28.09.20 14:22, Reindl Harald (h.rei...@thelounge.net) wrote:
> honestly: do you realize that i know very well how the memory management
> of Linux works and that it's pretty fine but not part of the topic at all?
Reindl, did you see who you are replying to here? Maybe don't try to
argue
Am 28.09.20 um 16:34 schrieb Dave Howorth:
> On Mon, 28 Sep 2020 14:10:38 +0200
> Reindl Harald wrote:
>> can you stop "reply-all" and breaking threads when respond to lists?
>
> I can't answer for the reply-all, that would annoy me as well.
> But the thread isn't broken, my MUA is showing it
On Mon, 28 Sep 2020 14:10:38 +0200
Reindl Harald wrote:
> can you stop "reply-all" and breaking threads when respond to lists?
I can't answer for the reply-all, that would annoy me as well.
But the thread isn't broken, my MUA is showing it nicely.
___
On Mon, Sep 28, 2020 at 02:22:17PM +0200, Reindl Harald wrote:
> honestly: do you realize that i know very well how the memory management
> of Linux works and that it's pretty fine but not part of the topic at all?
*plonk*
___
systemd-devel mailing list
honestly: do you realize that i know very well how the memory management
of Linux works and that it's pretty fine but not part of the topic at all?
Am 28.09.20 um 14:08 schrieb Greg KH:
> How do you know this? And why wouldn't they be "charged" to the task
> that caused the cache to fill up?
can you stop "reply-all" and breaking threads when respond to lists?
Am 28.09.20 um 13:55 schrieb Benjamin Berg:
> On Mon, 2020-09-28 at 11:37 +0200, Reindl Harald wrote:
>>
>> Am 28.09.20 um 11:19 schrieb Benjamin Berg:
if i would set "MemoryMax" to 4G "Memory: 8.6G" would kill it
when
On Mon, Sep 28, 2020 at 11:37:20AM +0200, Reindl Harald wrote:
>
>
> Am 28.09.20 um 11:19 schrieb Benjamin Berg:
> >> if i would set "MemoryMax" to 4G "Memory: 8.6G" would kill it when the
> >> caches are accounted in that context
> >
> > No, the kernel kicks in and reclaims memory at that
On Mon, 2020-09-28 at 11:37 +0200, Reindl Harald wrote:
>
> Am 28.09.20 um 11:19 schrieb Benjamin Berg:
> > > if i would set "MemoryMax" to 4G "Memory: 8.6G" would kill it
> > > when the
> > > caches are accounted in that context
> >
> > No, the kernel kicks in and reclaims memory at that point.
Hi Lennart,
sorry for the late reaction, thanks to your help (especially the busctl
monitor hint) I was able to figure out what was going on.
On Wed, Sep 09, 2020 at 06:31:26PM +0200, Lennart Poettering wrote:
[...]
> > At this point I am not sure if sd_bus actually behaves correctly and
> >
Am 28.09.20 um 11:19 schrieb Benjamin Berg:
>> if i would set "MemoryMax" to 4G "Memory: 8.6G" would kill it when the
>> caches are accounted in that context
>
> No, the kernel kicks in and reclaims memory at that point. Which can
> mean either swapping or just dropping caches.
caches have
On Mon, 2020-09-28 at 10:43 +0200, Reindl Harald wrote:
>
> Am 28.09.20 um 10:37 schrieb Tomasz Torcz:
> > On Mon, Sep 28, 2020 at 10:08:15AM +0200, Reindl Harald wrote:
> > > Am 27.09.20 um 23:39 schrieb Benjamin Berg:
> > > > > > > however, that value makes little to no sense and if that's the
Am 28.09.20 um 10:37 schrieb Tomasz Torcz:
> On Mon, Sep 28, 2020 at 10:08:15AM +0200, Reindl Harald wrote:
>> Am 27.09.20 um 23:39 schrieb Benjamin Berg:
>> however, that value makes little to no sense and if that's the same
>> value as accounted for "MemoryMax" it's plain wrong
>>>
On Mon, Sep 28, 2020 at 10:08:15AM +0200, Reindl Harald wrote:
> Am 27.09.20 um 23:39 schrieb Benjamin Berg:
> however, that value makes little to no sense and if that's the same
> value as accounted for "MemoryMax" it's plain wrong
> > But it does make sense. File caches are part of the
Am 27.09.20 um 23:39 schrieb Benjamin Berg:
however, that value makes little to no sense and if that's the same
value as accounted for "MemoryMax" it's plain wrong
> But it does make sense. File caches are part of the working set of
> memory that a process needs. Setting
19 matches
Mail list logo
