Re: Quickemu Problem with amount of RAM

[Geert Stappers]

On Sat, May 18, 2024 at 11:56:06AM -0400, Stephen P. Molnar wrote:
> I have just installed installed Quickemu v-6.1.4.
> 
>     quickget windows 11 ran as it should without any errors or warnings.
>     However:
>         (base) comp@Abanormal:~/VM$ quickemu --vm windows-10.conf
>     ~/VM ~/VM
>     Quickemu 4.9.4 using /usr/bin/qemu-system-x86_64 v7.2.9
>  - Host: Debian GNU/Linux 12 (bookworm) running Linux 6.1 (Abanormal)
>  - CPU:  AMD FX(tm)-8320 Eight-Core Processor
>  - CPU VM:   1 Socket(s), 2 Core(s), 2 Thread(s), 4G RAM
>     ERROR! You have insufficient RAM to run windows in a VM
>     (base) comp@Abanormal:~/VM$
> 
> I am somewhat confused as:
> 
>     (base) comp@Abanormal:~$ free -ght
>        total    used free    shared  buff/cache   available
>         Mem:   7.7Gi   2.3Gi    225Mi  34Mi   5.4Gi   5.3Gi
>         Swap:  975Mi    50Mi    925Mi
>     Total: 8.6Gi   2.4Gi    1.1Gi
> 
> The strange thing is that I have installed Windows 10 using QEMU/KVM
> virt-manager without any RAM problems at all.

I say: "without any **noted** RAM problems at all"
 

> Some guidance would be appreciated.

My guess is: 4Gb in the guest, requires much more 4Gb on the host.

 
> Thanks in advance.

Thank the mailinglist by sharing how you got beyond the hurdle.


Groeten
Geert Stappers
-- 
Silence is hard to parse

Re: RAM

[The Wanderer]

On 2023-06-12 at 17:47, Bret Busby wrote:

> On 13/6/23 04:52, The Wanderer wrote:

>> I have to apologize; I completely misremembered the name of the program
>> that I was referencing, probably because of the filenames I store its
>> output under. hwinfo is absolutely not it. I would not consider output
>> such as you presented to be appropriately readable for human
>> consumption.
>> 
>> Rather, I got the records I'm looking at from the program 'lshw'.
>> 
> Okay - so the equivalent output that describes the memory, from lshw, is
> 
> "
>   *-memory
>description: System Memory
>physical id: 2f
>slot: System board or motherboard
>size: 128GiB
>capabilities: ecc
>configuration: errordetection=multi-bit-ecc
>  *-bank:0
>   description: RIMM DDR4 Synchronous 2133 MHz (0.5 ns)
>   product: M393A2G40DB0-CPB
>   vendor: Samsung
>   physical id: 0
>   serial: 400F4723
>   slot: DIMM1
>   size: 16GiB
>   width: 64 bits
>   clock: 2133MHz (0.5ns)



> which may appear to be more "human" understandable, for expressing
> the capacity of each DIMM card in GiB, rather than in bytes,

Actually, that isn't what I found more readable about this. It's more
the separate indented blocks for each distinct item being described, and
the use of lowercase rather than ALL_CAPS field labels, that makes the
difference.

> but, I had no problem in finding and understanding the applicable
> output for describing the RAM component of the hardware.
> 
> If being able to adequately interpret the output from hwinfo, makes
> me other than human, well, such is life.

Oh, certainly not. I can read the other myself, it's just that I
understand myself as doing so through the lens of "thinking like a
computer", similarly to the mindset I find myself in when reading source
code.

> Both utilities work, and, work sufficiently.
> 
> hwinfo is simply less pretty than lshw.
> 
> But, it nevertheless, works.

It certainly does.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: RAM

[Bret Busby]

On 13/6/23 04:52, The Wanderer wrote:

On 2023-06-12 at 16:45, Bret Busby wrote:


On 13/6/23 04:30, The Wanderer wrote:


On 2023-06-12 at 16:06, Mick Ab wrote:


I wish to obtain information about the RAM installed on my PC using the
command line. The information needed is :-

Total RAM stored
Number of sticks used and amount of RAM on each stick
Type of RAM e.g. DDR4
Speed of RAM e.g. 3200 MHz
Manufacturer and model number of RAM

I have seen the dmidecode command being used, but the reliability of the
information returned is not reliable.

Is there any command that will reliably give the required RAM information ?


There are probably multiple ways to get it, but the first one that comes
to my mind involves the 'hwinfo' command, from the package of the same
name.

I don't remember exactly how I invoked it, but I have a historical trail
of files listing the hardware specifications of my last few machines as
they've changed over time, each generated from the output of that
command.


If I search the latest such file for "DIMM", I see two entries, each for
a different DIMM (i.e., "RAM stick"), each with multiple data items. The
fact that there are two of them gives you the "number of sticks used"
you asked for.

Those entries are sub-entries of a larger entry called "memory", which
has a data item called "size", which is the "total RAM" you asked for.

One of the data items in each sub-entry is "product", which appears as
if it might be the "model number" you asked for. (It certainly looks
like a model number, anyway.)

Another is "vendor", which appears to be the "manufacturer" you asked
for.

Another is "size", which gives you the "amount of RAM on each stick" you
asked for.

Another is "clock", which is the "speed of RAM" you asked for.

Another is "description", which at least in my case specifies (as part
of what appears to be a freeform string) that the DIMMs I'm looking at
are DDR4. I don't see that information specified anywhere else in the
listing.


  From the above, whilst this computer is running Linux Mint Mate 21.1,
which is based (?) on Ubuntu 22.04 ("jammy"), rather than Debian, I
expect that the same will apply for Debian;



Tue Jun 13 04:33:23 bret@bret-Precision-Tower-5810:~$hwinfo



and, in the output (lots of it - it outputs alot of details), is

"
P: /devices/virtual/dmi/id
L: 0
E: DEVPATH=/devices/virtual/dmi/id
E: SUBSYSTEM=dmi
E:
MODALIAS=dmi:bvnDellInc.:bvrA34:bd10/19/2020:br65.34:svnDellInc.:pnPrecisionTower5810:pvr:rvnDellInc.:rn0K240Y:rvrA02:cvnDellInc.:ct7:cvr:sku0617:
E: USEC_INITIALIZED=2533353
E: ID_VENDOR=Dell Inc.
E: ID_MODEL=Precision Tower 5810
E: MEMORY_ARRAY_LOCATION=System Board Or Motherboard
E: MEMORY_ARRAY_EC_TYPE=Multi-bit ECC
E: MEMORY_ARRAY_MAX_CAPACITY=137438953472




I have to apologize; I completely misremembered the name of the program
that I was referencing, probably because of the filenames I store its
output under. hwinfo is absolutely not it. I would not consider output
such as you presented to be appropriately readable for human
consumption.

Rather, I got the records I'm looking at from the program 'lshw'.


Okay - so the equivalent output that describes the memory, from lshw, is

"
 *-memory
  description: System Memory
  physical id: 2f
  slot: System board or motherboard
  size: 128GiB
  capabilities: ecc
  configuration: errordetection=multi-bit-ecc
*-bank:0
 description: RIMM DDR4 Synchronous 2133 MHz (0.5 ns)
 product: M393A2G40DB0-CPB
 vendor: Samsung
 physical id: 0
 serial: 400F4723
 slot: DIMM1
 size: 16GiB
 width: 64 bits
 clock: 2133MHz (0.5ns)
*-bank:1
 description: RIMM DDR4 Synchronous 2133 MHz (0.5 ns)
 product: M393A2G40DB0-CPB
 vendor: Samsung
 physical id: 1
 serial: 39FDE464
 slot: DIMM5
 size: 16GiB
 width: 64 bits
 clock: 2133MHz (0.5ns)
*-bank:2
 description: RIMM DDR4 Synchronous 2133 MHz (0.5 ns)
 product: M393A2G40DB0-CPB
 vendor: Samsung
 physical id: 2
 serial: 400F473D
 slot: DIMM3
 size: 16GiB
 width: 64 bits
 clock: 2133MHz (0.5ns)
*-bank:3
 description: RIMM DDR4 Synchronous 2133 MHz (0.5 ns)
 product: M393A2G40DB0-CPB
 vendor: Samsung
 physical id: 3
 serial: 39FDD7B6
 slot: DIMM7
 size: 16GiB
 width: 64 bits
 clock: 2133MHz (0.5ns)
*-bank:4
 

Re: RAM

[Dan Ritter]

Mick Ab wrote: 
> I have seen the dmidecode command being used, but the reliability of the
> information returned is not reliable.

You keep saying that, but have you got any evidence of it? And
if so, it is the unreliability of omission or making things up,
or being random in the returned data?

-dsr-

Re: RAM

[The Wanderer]

On 2023-06-12 at 16:45, Bret Busby wrote:

> On 13/6/23 04:30, The Wanderer wrote:
>
>> On 2023-06-12 at 16:06, Mick Ab wrote:
>> 
>>> I wish to obtain information about the RAM installed on my PC using the
>>> command line. The information needed is :-
>>>
>>> Total RAM stored
>>> Number of sticks used and amount of RAM on each stick
>>> Type of RAM e.g. DDR4
>>> Speed of RAM e.g. 3200 MHz
>>> Manufacturer and model number of RAM
>>>
>>> I have seen the dmidecode command being used, but the reliability of the
>>> information returned is not reliable.
>>>
>>> Is there any command that will reliably give the required RAM information ?
>> 
>> There are probably multiple ways to get it, but the first one that comes
>> to my mind involves the 'hwinfo' command, from the package of the same
>> name.
>> 
>> I don't remember exactly how I invoked it, but I have a historical trail
>> of files listing the hardware specifications of my last few machines as
>> they've changed over time, each generated from the output of that
>> command.
>> 
>> 
>> If I search the latest such file for "DIMM", I see two entries, each for
>> a different DIMM (i.e., "RAM stick"), each with multiple data items. The
>> fact that there are two of them gives you the "number of sticks used"
>> you asked for.
>> 
>> Those entries are sub-entries of a larger entry called "memory", which
>> has a data item called "size", which is the "total RAM" you asked for.
>> 
>> One of the data items in each sub-entry is "product", which appears as
>> if it might be the "model number" you asked for. (It certainly looks
>> like a model number, anyway.)
>> 
>> Another is "vendor", which appears to be the "manufacturer" you asked
>> for.
>> 
>> Another is "size", which gives you the "amount of RAM on each stick" you
>> asked for.
>> 
>> Another is "clock", which is the "speed of RAM" you asked for.
>> 
>> Another is "description", which at least in my case specifies (as part
>> of what appears to be a freeform string) that the DIMMs I'm looking at
>> are DDR4. I don't see that information specified anywhere else in the
>> listing.
> 
>  From the above, whilst this computer is running Linux Mint Mate 21.1, 
> which is based (?) on Ubuntu 22.04 ("jammy"), rather than Debian, I 
> expect that the same will apply for Debian;

> Tue Jun 13 04:33:23 bret@bret-Precision-Tower-5810:~$hwinfo

> and, in the output (lots of it - it outputs alot of details), is
> 
> "
> P: /devices/virtual/dmi/id
>L: 0
>E: DEVPATH=/devices/virtual/dmi/id
>E: SUBSYSTEM=dmi
>E: 
> MODALIAS=dmi:bvnDellInc.:bvrA34:bd10/19/2020:br65.34:svnDellInc.:pnPrecisionTower5810:pvr:rvnDellInc.:rn0K240Y:rvrA02:cvnDellInc.:ct7:cvr:sku0617:
>E: USEC_INITIALIZED=2533353
>E: ID_VENDOR=Dell Inc.
>E: ID_MODEL=Precision Tower 5810
>E: MEMORY_ARRAY_LOCATION=System Board Or Motherboard
>E: MEMORY_ARRAY_EC_TYPE=Multi-bit ECC
>E: MEMORY_ARRAY_MAX_CAPACITY=137438953472



I have to apologize; I completely misremembered the name of the program
that I was referencing, probably because of the filenames I store its
output under. hwinfo is absolutely not it. I would not consider output
such as you presented to be appropriately readable for human
consumption.

Rather, I got the records I'm looking at from the program 'lshw'.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw

Re: RAM

[Bret Busby]

On 13/6/23 04:30, The Wanderer wrote:

On 2023-06-12 at 16:06, Mick Ab wrote:


I wish to obtain information about the RAM installed on my PC using the
command line. The information needed is :-

Total RAM stored
Number of sticks used and amount of RAM on each stick
Type of RAM e.g. DDR4
Speed of RAM e.g. 3200 MHz
Manufacturer and model number of RAM

I have seen the dmidecode command being used, but the reliability of the
information returned is not reliable.

Is there any command that will reliably give the required RAM information ?


There are probably multiple ways to get it, but the first one that comes
to my mind involves the 'hwinfo' command, from the package of the same
name.

I don't remember exactly how I invoked it, but I have a historical trail
of files listing the hardware specifications of my last few machines as
they've changed over time, each generated from the output of that
command.


If I search the latest such file for "DIMM", I see two entries, each for
a different DIMM (i.e., "RAM stick"), each with multiple data items. The
fact that there are two of them gives you the "number of sticks used"
you asked for.

Those entries are sub-entries of a larger entry called "memory", which
has a data item called "size", which is the "total RAM" you asked for.

One of the data items in each sub-entry is "product", which appears as
if it might be the "model number" you asked for. (It certainly looks
like a model number, anyway.)

Another is "vendor", which appears to be the "manufacturer" you asked
for.

Another is "size", which gives you the "amount of RAM on each stick" you
asked for.

Another is "clock", which is the "speed of RAM" you asked for.

Another is "description", which at least in my case specifies (as part
of what appears to be a freeform string) that the DIMMs I'm looking at
are DDR4. I don't see that information specified anywhere else in the
listing.



From the above, whilst this computer is running Linux Mint Mate 21.1, 
which is based (?) on Ubuntu 22.04 ("jammy"), rather than Debian, I 
expect that the same will apply for Debian;


"
Tue Jun 13 04:32:24 bret@bret-Precision-Tower-5810:~$hwinfo
Command 'hwinfo' not found, but can be installed with:
sudo apt install hwinfo
Tue Jun 13 04:32:40 bret@bret-Precision-Tower-5810:~$sudo apt install hwinfo
[sudo] password for bret:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libhd21 libx86emu3
The following NEW packages will be installed
  hwinfo libhd21 libx86emu3
0 to upgrade, 3 to newly install, 0 to remove and 5 not to upgrade.
Need to get 808 kB of archives.
After this operation, 3,581 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://archive.ubuntu.com/ubuntu jammy/universe amd64 libx86emu3 
amd64 3.1-2 [47.8 kB]
Get:2 http://archive.ubuntu.com/ubuntu jammy/universe amd64 libhd21 
amd64 21.72-1 [742 kB]
Get:3 http://archive.ubuntu.com/ubuntu jammy/universe amd64 hwinfo amd64 
21.72-1 [18.0 kB]

Fetched 808 kB in 3s (266 kB/s)
Selecting previously unselected package libx86emu3:amd64.
(Reading database ... 540233 files and directories currently installed.)
Preparing to unpack .../libx86emu3_3.1-2_amd64.deb ...
Unpacking libx86emu3:amd64 (3.1-2) ...
Selecting previously unselected package libhd21:amd64.
Preparing to unpack .../libhd21_21.72-1_amd64.deb ...
Unpacking libhd21:amd64 (21.72-1) ...
Selecting previously unselected package hwinfo.
Preparing to unpack .../hwinfo_21.72-1_amd64.deb ...
Unpacking hwinfo (21.72-1) ...
Setting up libx86emu3:amd64 (3.1-2) ...
Setting up libhd21:amd64 (21.72-1) ...
Setting up hwinfo (21.72-1) ...
Processing triggers for man-db (2.10.2-1) ...
Processing triggers for libc-bin (2.35-0ubuntu3.1) ...
Tue Jun 13 04:33:23 bret@bret-Precision-Tower-5810:~$hwinfo
"

and, in the output (lots of it - it outputs alot of details), is

"
P: /devices/virtual/dmi/id
  L: 0
  E: DEVPATH=/devices/virtual/dmi/id
  E: SUBSYSTEM=dmi
  E: 
MODALIAS=dmi:bvnDellInc.:bvrA34:bd10/19/2020:br65.34:svnDellInc.:pnPrecisionTower5810:pvr:rvnDellInc.:rn0K240Y:rvrA02:cvnDellInc.:ct7:cvr:sku0617:

  E: USEC_INITIALIZED=2533353
  E: ID_VENDOR=Dell Inc.
  E: ID_MODEL=Precision Tower 5810
  E: MEMORY_ARRAY_LOCATION=System Board Or Motherboard
  E: MEMORY_ARRAY_EC_TYPE=Multi-bit ECC
  E: MEMORY_ARRAY_MAX_CAPACITY=137438953472
  E: MEMORY_DEVICE_0_TOTAL_WIDTH=72
  E: MEMORY_DEVICE_0_DATA_WIDTH=64
  E: MEMORY_DEVICE_0_SIZE=17179869184
  E: MEMORY_DEVICE_0_FORM_FACTOR=RIMM
  E: MEMORY_DEVICE_0_LOCATOR=DIMM1
  E: MEMORY_DEVICE_0_BANK_LOCATOR=Not Specified
  E: MEMORY_DEVICE_0_TYPE=DDR4
  E: MEMORY_DEVICE_0_TYPE_DETAIL=Synchronous
  E: MEMORY_DEVICE_0_SPEED_M

Re: RAM in inxi

[Felix Miata]

Roger Price composed on 2023-06-12 22:25 (UTC+0200):

> According to man inxi the command "inxi -mxx" tries to improve on dmidecode.

h2 on irc://irc.oftc.net/smxi (IRC) is inxi's creator. 3.3.27-00 is the current
version, released on 2023-05-07. The devel version is named pinxi, currently at
3.3.27-12, released yesterday. https://smxi.org/ is author's home page, which
links to his own forum.

3.3.27-12 contains a WIP of memory reporting improvements. If you wish to be 
heard
on the subject, or have questions about or problems with pinxi, h2 is all ears.

Maximum RAM reporting in inxi comes from -ma:

# inxi -mxx --vs
inxi 3.3.27-00 (2023-05-07)
Memory:
  System RAM: available: 30.29 GiB used: 14.99 GiB (49.5%)
  Array-1: capacity: 32 GiB slots: 4 EC: None max-module-size: 8 GiB
note: est.
  Device-1: ChannelA-DIMM0 type: DDR3 size: 8 GiB speed: 1600 MT/s
volts: 1.5 manufacturer: Corsair part-no: CML16GX3M2A1600C9
  Device-2: ChannelA-DIMM1 type: DDR3 size: 8 GiB speed: 1600 MT/s
volts: 1.5 manufacturer: Mushkin part-no: 992069 (997069)
  Device-3: ChannelB-DIMM0 type: DDR3 size: 8 GiB speed: 1600 MT/s
volts: 1.5 manufacturer: Corsair part-no: CML16GX3M2A1600C9
  Device-4: ChannelB-DIMM1 type: DDR3 size: 8 GiB speed: 1600 MT/s
volts: 1.5 manufacturer: Mushkin part-no: 992069 (997069)
# pinxi -ma --vs
pinxi 3.3.27-12 (2023-06-12)
Memory:
  System RAM: total: 32 GiB available: 30.29 GiB used: 15.02 GiB (49.6%)
igpu: 544 MiB
  Array-1: capacity: 32 GiB slots: 4 modules: 4 EC: None
max-module-size: 8 GiB note: est.
  Device-1: ChannelA-DIMM0 type: DDR3 detail: synchronous size: 8 GiB
speed: 1600 MT/s volts: curr: 1.5 min: 1.5 max: 1.5 width (bits): data: 64
total: 64 manufacturer: Corsair part-no: CML16GX3M2A1600C9 serial: N/A
  Device-2: ChannelA-DIMM1 type: DDR3 detail: synchronous size: 8 GiB
speed: 1600 MT/s volts: curr: 1.5 min: 1.5 max: 1.5 width (bits): data: 64
total: 64 manufacturer: Mushkin part-no: 992069 (997069) serial: N/A
  Device-3: ChannelB-DIMM0 type: DDR3 detail: synchronous size: 8 GiB
speed: 1600 MT/s volts: curr: 1.5 min: 1.5 max: 1.5 width (bits): data: 64
total: 64 manufacturer: Corsair part-no: CML16GX3M2A1600C9 serial: N/A
  Device-4: ChannelB-DIMM1 type: DDR3 detail: synchronous size: 8 GiB
speed: 1600 MT/s volts: curr: 1.5 min: 1.5 max: 1.5 width (bits): data: 64
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: RAM

[The Wanderer]

On 2023-06-12 at 16:06, Mick Ab wrote:

> I wish to obtain information about the RAM installed on my PC using the
> command line. The information needed is :-
> 
> Total RAM stored
> Number of sticks used and amount of RAM on each stick
> Type of RAM e.g. DDR4
> Speed of RAM e.g. 3200 MHz
> Manufacturer and model number of RAM
> 
> I have seen the dmidecode command being used, but the reliability of the
> information returned is not reliable.
> 
> Is there any command that will reliably give the required RAM information ?

There are probably multiple ways to get it, but the first one that comes
to my mind involves the 'hwinfo' command, from the package of the same
name.

I don't remember exactly how I invoked it, but I have a historical trail
of files listing the hardware specifications of my last few machines as
they've changed over time, each generated from the output of that
command.


If I search the latest such file for "DIMM", I see two entries, each for
a different DIMM (i.e., "RAM stick"), each with multiple data items. The
fact that there are two of them gives you the "number of sticks used"
you asked for.

Those entries are sub-entries of a larger entry called "memory", which
has a data item called "size", which is the "total RAM" you asked for.

One of the data items in each sub-entry is "product", which appears as
if it might be the "model number" you asked for. (It certainly looks
like a model number, anyway.)

Another is "vendor", which appears to be the "manufacturer" you asked
for.

Another is "size", which gives you the "amount of RAM on each stick" you
asked for.

Another is "clock", which is the "speed of RAM" you asked for.

Another is "description", which at least in my case specifies (as part
of what appears to be a freeform string) that the DIMMs I'm looking at
are DDR4. I don't see that information specified anywhere else in the
listing.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: RAM

[Roger Price]

On Mon, 12 Jun 2023, Mick Ab wrote:


I have seen the dmidecode command being used, but the reliability of the 
information returned is not reliable.
Is there any command that will reliably give the required RAM information ?


According to man inxi the command "inxi -mxx" tries to improve on dmidecode.

Quoting from man inxi :  Because dmidecode data is extremely unreliable, inxi 
will try to make best guesses.  If you see (check) after the capacity number, 
you should check it with the specifications. (est) is slightly more reliable, 
but you should still check the real specifications before buying RAM. 
Unfortunately there is nothing inxi can do to get truly reliable data about the 
system RAM;  maybe one day the kernel devs will put this data into /sys, and 
make it real data, taken from the actual system, not dmi data. For most people, 
the data will be right, but a significant percentage of users will have either a 
wrong max module size, if present, or max capacity.


Roger

Re: RAM

[Charles Curley]

On Mon, 12 Jun 2023 21:06:06 +0100
Mick Ab  wrote:

> I have seen the dmidecode command being used, but the reliability of
> the information returned is not reliable.
> 
> Is there any command that will reliably give the required RAM
> information ?

Any tool, dmidecode included, is no better than the date it operates
on. If dmidecode is returning bogus data, so will any other tool.

Dmidecode relies on information in ROM. Your alternatives are:

* A physical inventory, i.e. shut the machine down, take a screwdriver
  to it, and look at what's in there.

* A program that shuts off virtual memory and does an inventory by
  testing the RAM. And that has its own problems.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

RAM

[Mick Ab]

I wish to obtain information about the RAM installed on my PC using the
command line. The information needed is :-

Total RAM stored
Number of sticks used and amount of RAM on each stick
Type of RAM e.g. DDR4
Speed of RAM e.g. 3200 MHz
Manufacturer and model number of RAM

I have seen the dmidecode command being used, but the reliability of the
information returned is not reliable.

Is there any command that will reliably give the required RAM information ?

Re: Fwd: Clearing RAM Caches

[Tixy]

On Tue, 2022-08-16 at 07:24 -0400, Greg Wooledge wrote:
> The following two commands are equivalent:
> 
> echo 1 > sudo /proc/sys/vm/drop_caches
> 
> echo 1 /proc/sys/vm/drop_caches > sudo
> 
> The file "sudo" will have "1 /proc/sys/vm/drop_caches" in it, because
> echo received two arguments.  Redirections may appear anywhere in a
> "simple" command.  It's conventional to write them at the end of the
> command, but the shell permits them to be anywhere.
> 
> This is a standard feature of all POSIX shells, by the way.  Not a
> bash extension.

I should have remembered this as I learnt it a couple of years ago when
implementing a POSIX shell (subset thereof).

-- 
Tixy

Re: Fwd: Clearing RAM Caches

[Greg Wooledge]

On Tue, Aug 16, 2022 at 08:25:12AM +0100, Tixy wrote:
> On Mon, 2022-08-15 at 21:05 -0400, Timothy M Butterworth wrote:
> > > 
> > Thanks for the clarification. `echo 1 > sudo /proc/sys/vm/drop_caches`
> > seems to work just fine.
> 
> It doesn't, as Tomas pointed out it creates a file called 'sudo' and
> puts a '1' in it.

The following two commands are equivalent:

echo 1 > sudo /proc/sys/vm/drop_caches

echo 1 /proc/sys/vm/drop_caches > sudo

The file "sudo" will have "1 /proc/sys/vm/drop_caches" in it, because
echo received two arguments.  Redirections may appear anywhere in a
"simple" command.  It's conventional to write them at the end of the
command, but the shell permits them to be anywhere.

This is a standard feature of all POSIX shells, by the way.  Not a
bash extension.

Redirections must appear at the end of "compound" commands, which are
basically anything with internal shell syntax -- if, case, while, and
so on.  It may be desirable to try to write something like:

< inputfile  while read -r line; do
  ...
done

but it's not allowed.  You have to write it as:

while read -r line; do
  ...
done < inputfile

Or, explicitly open the input file on a new FD (file descriptor), and
close it afterward:

exec 3< inputfile
while read -r line <&3; do
  ...
done
exec 3<&-

Re: Fwd: Clearing RAM Caches

[Timothy M Butterworth]

On Tue, Aug 16, 2022 at 12:36 AM  wrote:

> On Mon, Aug 15, 2022 at 09:05:59PM -0400, Timothy M Butterworth wrote:
> > -- Forwarded message -
> > From: Timothy M Butterworth 
> > Date: Mon, Aug 15, 2022 at 9:04 PM
> > Subject: Re: Clearing RAM Caches
> > To: Tixy 
> >
> >
> >
> >
> > On Mon, Aug 15, 2022 at 4:12 AM Tixy  wrote:
> >
> > > On Mon, 2022-08-15 at 02:50 -0400, Timothy M Butterworth wrote:
> > > > When I run `sudo echo 1 > /proc/sys/vm/drop_caches` I receive the
> > > following
> > > > error: bash: /proc/sys/vm/drop_caches: Permission denied
> > >
> > > Because the output redirection occurs as your normal user, all you are
> > > doing is executing the 'echo 1' command as the superuser.
> > >
> > >
> > Thanks for the clarification. `echo 1 > sudo /proc/sys/vm/drop_caches`
> > seems to work just fine.
>
> This is... surprising. If I were you, I'd look around in the current
> directory whether there's a file named `sudo' with an "1" in it.
>
> You are correct I did have a file named sudo with "1
/proc/sys/vm/drop_caches" in it.

It looks like `sudo sh -c "/usr/bin/echo 1 > /proc/sys/vm/drop_caches"` is
the winner.


> Cheers
> --
> t
>


-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: Fwd: Clearing RAM Caches

[Tixy]

On Mon, 2022-08-15 at 21:05 -0400, Timothy M Butterworth wrote:
> > 
> Thanks for the clarification. `echo 1 > sudo /proc/sys/vm/drop_caches`
> seems to work just fine.

It doesn't, as Tomas pointed out it creates a file called 'sudo' and
puts a '1' in it.

Output redirection done with a single '>' is implemented by the shell
first creating the specified file and then when it forks a process for
the command ('echo' in this case) it makes file descriptor number 1 in
that process (the descriptor used by convention and Standard Output)
refer to the file opened.

The reply you got from Anssi Saari gave an example of a command that
will do what you want.

-- 
Tixy

Re: Fwd: Clearing RAM Caches

[tomas]

On Mon, Aug 15, 2022 at 09:05:59PM -0400, Timothy M Butterworth wrote:
> -- Forwarded message -
> From: Timothy M Butterworth 
> Date: Mon, Aug 15, 2022 at 9:04 PM
> Subject: Re: Clearing RAM Caches
> To: Tixy 
> 
> 
> 
> 
> On Mon, Aug 15, 2022 at 4:12 AM Tixy  wrote:
> 
> > On Mon, 2022-08-15 at 02:50 -0400, Timothy M Butterworth wrote:
> > > When I run `sudo echo 1 > /proc/sys/vm/drop_caches` I receive the
> > following
> > > error: bash: /proc/sys/vm/drop_caches: Permission denied
> >
> > Because the output redirection occurs as your normal user, all you are
> > doing is executing the 'echo 1' command as the superuser.
> >
> >
> Thanks for the clarification. `echo 1 > sudo /proc/sys/vm/drop_caches`
> seems to work just fine.

This is... surprising. If I were you, I'd look around in the current
directory whether there's a file named `sudo' with an "1" in it.

Cheers
-- 
t


signature.asc
Description: PGP signature

Fwd: Clearing RAM Caches

[Timothy M Butterworth]

-- Forwarded message -
From: Timothy M Butterworth 
Date: Mon, Aug 15, 2022 at 9:04 PM
Subject: Re: Clearing RAM Caches
To: Tixy 




On Mon, Aug 15, 2022 at 4:12 AM Tixy  wrote:

> On Mon, 2022-08-15 at 02:50 -0400, Timothy M Butterworth wrote:
> > When I run `sudo echo 1 > /proc/sys/vm/drop_caches` I receive the
> following
> > error: bash: /proc/sys/vm/drop_caches: Permission denied
>
> Because the output redirection occurs as your normal user, all you are
> doing is executing the 'echo 1' command as the superuser.
>
>
Thanks for the clarification. `echo 1 > sudo /proc/sys/vm/drop_caches`
seems to work just fine.


> --
> Tixy
>
>

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀


-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: Clearing RAM Caches

[Nicolas George]

to...@tuxteam.de (12022-08-15):
>   echo 1 | sudo dd of=/proc/sys/and-so-on

sudo sh -c "echo 1 > /proc/sys/and-so-on"

Or, in this particular case:

sudo systcl -w and-so-on=1

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: Clearing RAM Caches

[tomas]

On Mon, Aug 15, 2022 at 11:13:07AM +0300, Anssi Saari wrote:
> Timothy M Butterworth  writes:
> 
> > When I run `sudo echo 1 > /proc/sys/vm/drop_caches` I receive the following 
> > error: bash: /proc/sys/vm/drop_caches: Permission denied
> 
> Unfortunately, it's your current shell and not root who does the
> redirection in this case so no permissions.
> 
> For a longer explanation see
> https://www.reddit.com/r/linux4noobs/comments/qq76qo/sudo_echo_vs_echo_from_the_root_shell/
> 
> A proposed alternative from there is to use tee, like this:
> 
> echo 1 | sudo tee /proc/sys/vm/drop_caches

To add another one, I like dd for that one (it doesn't clutter
stdout unnecessarily).

  echo 1 | sudo dd of=/proc/sys/and-so-on

Embarrasment of riches!

Basically, what one is looking for is a cat one can pass an
output file name as a command line argument -- or put another
way, a cat which opens its output itself.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Clearing RAM Caches

[Anssi Saari]

Timothy M Butterworth  writes:

> When I run `sudo echo 1 > /proc/sys/vm/drop_caches` I receive the following 
> error: bash: /proc/sys/vm/drop_caches: Permission denied

Unfortunately, it's your current shell and not root who does the
redirection in this case so no permissions.

For a longer explanation see
https://www.reddit.com/r/linux4noobs/comments/qq76qo/sudo_echo_vs_echo_from_the_root_shell/

A proposed alternative from there is to use tee, like this:

echo 1 | sudo tee /proc/sys/vm/drop_caches

Re: Clearing RAM Caches

[Tixy]

On Mon, 2022-08-15 at 02:50 -0400, Timothy M Butterworth wrote:
> When I run `sudo echo 1 > /proc/sys/vm/drop_caches` I receive the following
> error: bash: /proc/sys/vm/drop_caches: Permission denied

Because the output redirection occurs as your normal user, all you are
doing is executing the 'echo 1' command as the superuser.

-- 
Tixy

Clearing RAM Caches

[Timothy M Butterworth]

When I run `sudo echo 1 > /proc/sys/vm/drop_caches` I receive the following
error: bash: /proc/sys/vm/drop_caches: Permission denied

I have `%sudo   ALL=(ALL:ALL) ALL` in my /etc/sudoers file. All commands
should be allowed for group sudo.

ls -la /proc/sys/vm/drop_caches
--w--- 1 root root 0 Aug 14 16:28 /proc/sys/vm/drop_caches

I tried adding group permissions with `sudo chmod 440
/proc/sys/vm/drop_caches` and receive the following error message chmod:
changing permissions of '/proc/sys/vm/drop_caches': Operation not permitted

If I run `sudo sh -c "/usr/bin/echo 1 > /proc/sys/vm/drop_caches"` it
works.  Why does  `sudo echo 1 > /proc/sys/vm/drop_caches` not work, so
frustrating.

Tim

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: swap maxed out when plenty of RAM available

[Nicholas Geovanis]

On Fri, Mar 25, 2022 at 12:27 PM Greg Wooledge  wrote:

> On Fri, Mar 25, 2022 at 04:51:51PM +, Adam Weremczuk wrote:
> > [Tue Mar 22 00:24:10 2022] Tasks state (memory values in pages):
> > [Tue Mar 22 00:24:10 2022] [  pid  ]   uid  tgid total_vm  rss
> > pgtables_bytes swapents oom_score_adj name
> > [Tue Mar 22 00:24:10 2022] [   2211] 0  221114228 228
> 159744
> > 127 0 systemd
> > [Tue Mar 22 00:24:10 2022] [   2622] 0  262293208 59485
> > 753664   73 0 systemd-journal
>
> Well, at this point systemd-journald (I assume the name is truncated)
> was using more memory than anything else.
> .

> [Tue Mar 22 00:24:10 2022] Memory cgroup out of memory: Killed process
> 11695
>
> So, next it killed dhcpd.  And it still wasn't done.
>
> > [Tue Mar 22 00:24:10 2022] [  21057] 0 21057 1069 31
> 53248
> > 0 0 apt.systemd.dai
> > [Tue Mar 22 00:24:10 2022] [  21065] 0 2106517753 2552
> > 1802240 0 apt-get
> > [Tue Mar 22 00:24:10 2022] [  21068] 0 21068 9475 110
> > 1105920 0 systemd-journal
> > [Tue Mar 22 00:24:10 2022]
> oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=ns,mems_allowed=0-1,oom_memcg=/lxc/101,task_memcg=/lxc/101/ns,task=apt-get,pid=21065,uid=0
> > [Tue Mar 22 00:24:10 2022] Memory cgroup out of memory: Killed process
> 21065
>
> At this point, it killed apt-get.
>
> Looks like this system doesn't have enough memory to perform its daily
> tasks (including what I'm guessing are unattended upgrades, triggering
> calls to apt-get from a systemd timer).  You'll either need to stop
> letting it run those daily tasks, or add more memory, or add more swap,
> or get rid of some of the other programs that are using memory.
>

If you have re-configured your apt repositories but made a mistake, or lost
contact with them for
other network reasons, you will see those automated apt-get commands
stack-up over time.
They reach a point in execution where they acquire a lock that blocks all
other updates, so just
keep piling up. Each consumes swap. If the CPU workload is the local
bottleneck you may notice
a CPU or two pegged at 100% as the first symptom.


> If you really want the unattended upgrades, adding more swap would be
> the easiest solution, but be warned that this could mean the system
> will run extremely slowly during those unattended upgrades.  That could
> be something you don't care about, or something that matters a lot.  Only
> you would know.
>

If it's a server, servers should not swap and they should not get upgraded
without purpose.

Re: swap maxed out when plenty of RAM available

[Greg Wooledge]

On Fri, Mar 25, 2022 at 04:51:51PM +, Adam Weremczuk wrote:
> [Tue Mar 22 00:24:10 2022] Tasks state (memory values in pages):
> [Tue Mar 22 00:24:10 2022] [  pid  ]   uid  tgid total_vm  rss
> pgtables_bytes swapents oom_score_adj name
> [Tue Mar 22 00:24:10 2022] [   2211] 0  2211    14228 228   159744 
> 127 0 systemd
> [Tue Mar 22 00:24:10 2022] [   2622] 0  2622    93208 59485  
> 753664   73 0 systemd-journal

Well, at this point systemd-journald (I assume the name is truncated)
was using more memory than anything else.

> [Tue Mar 22 00:24:10 2022] 
> oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=ns,mems_allowed=0-1,oom_memcg=/lxc/101,task_memcg=/lxc/101/ns,task=systemd-journal,pid=2622,uid=0
> [Tue Mar 22 00:24:10 2022] Memory cgroup out of memory: Killed process 2622

And the kernel killed it.

But there still wasn't enough memory, so it continued:

> [Tue Mar 22 00:24:10 2022] pgsteal 9855948
> [Tue Mar 22 00:24:10 2022] Tasks state (memory values in pages):
> [Tue Mar 22 00:24:10 2022] [  pid  ]   uid  tgid total_vm  rss
> pgtables_bytes swapents oom_score_adj name
> [Tue Mar 22 00:24:10 2022] [   2211] 0  2211    14228 228   159744 
> 127 0 systemd
[...]
> [Tue Mar 22 00:24:10 2022] [  11695] 0 11695    10289 2685  
> 114688    0 0 dhcpd
[...]
> [Tue Mar 22 00:24:10 2022] [  21053] 0 21053 1069 17    53248   
> 0 0 apt.systemd.dai
> [Tue Mar 22 00:24:10 2022] [  21057] 0 21057 1069 31    53248   
> 0 0 apt.systemd.dai
> [Tue Mar 22 00:24:10 2022] [  21065] 0 21065    17753 1712  
> 180224    0 0 apt-get
> [Tue Mar 22 00:24:10 2022] 
> oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=ns,mems_allowed=0-1,oom_memcg=/lxc/101,task_memcg=/lxc/101/ns,task=dhcpd,pid=11695,uid=0
> [Tue Mar 22 00:24:10 2022] Memory cgroup out of memory: Killed process 11695

So, next it killed dhcpd.  And it still wasn't done.

> [Tue Mar 22 00:24:10 2022] [  21057] 0 21057 1069 31    53248   
> 0 0 apt.systemd.dai
> [Tue Mar 22 00:24:10 2022] [  21065] 0 21065    17753 2552  
> 180224    0 0 apt-get
> [Tue Mar 22 00:24:10 2022] [  21068] 0 21068 9475 110  
> 110592    0 0 systemd-journal
> [Tue Mar 22 00:24:10 2022] 
> oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=ns,mems_allowed=0-1,oom_memcg=/lxc/101,task_memcg=/lxc/101/ns,task=apt-get,pid=21065,uid=0
> [Tue Mar 22 00:24:10 2022] Memory cgroup out of memory: Killed process 21065

At this point, it killed apt-get.

Looks like this system doesn't have enough memory to perform its daily
tasks (including what I'm guessing are unattended upgrades, triggering
calls to apt-get from a systemd timer).  You'll either need to stop
letting it run those daily tasks, or add more memory, or add more swap,
or get rid of some of the other programs that are using memory.

If you really want the unattended upgrades, adding more swap would be
the easiest solution, but be warned that this could mean the system
will run extremely slowly during those unattended upgrades.  That could
be something you don't care about, or something that matters a lot.  Only
you would know.

Re: swap maxed out when plenty of RAM available

[Adam Weremczuk]

 2022] slab 12877824
[Tue Mar 22 00:24:10 2022] sock 0
[Tue Mar 22 00:24:10 2022] shmem 506744832
[Tue Mar 22 00:24:10 2022] file_mapped 270336
[Tue Mar 22 00:24:10 2022] file_dirty 0
[Tue Mar 22 00:24:10 2022] file_writeback 135168
[Tue Mar 22 00:24:10 2022] anon_thp 0
[Tue Mar 22 00:24:10 2022] inactive_anon 264527872
[Tue Mar 22 00:24:10 2022] active_anon 256671744
[Tue Mar 22 00:24:10 2022] inactive_file 905216
[Tue Mar 22 00:24:10 2022] active_file 0
[Tue Mar 22 00:24:10 2022] unevictable 0
[Tue Mar 22 00:24:10 2022] slab_reclaimable 6713344
[Tue Mar 22 00:24:10 2022] slab_unreclaimable 6164480
[Tue Mar 22 00:24:10 2022] pgfault 1443488376
[Tue Mar 22 00:24:10 2022] pgmajfault 9734703
[Tue Mar 22 00:24:10 2022] workingset_refault 9720216
[Tue Mar 22 00:24:10 2022] workingset_activate 2073753
[Tue Mar 22 00:24:10 2022] workingset_nodereclaim 0
[Tue Mar 22 00:24:10 2022] pgrefill 12141300
[Tue Mar 22 00:24:10 2022] pgscan 18087447
[Tue Mar 22 00:24:10 2022] pgsteal 9866147
[Tue Mar 22 00:24:10 2022] Tasks state (memory values in pages):
[Tue Mar 22 00:24:10 2022] [  pid  ]   uid  tgid total_vm  rss 
pgtables_bytes swapents oom_score_adj name
[Tue Mar 22 00:24:10 2022] [   2211] 0  2211    14228 230   
159744  125 0 systemd
[Tue Mar 22 00:24:10 2022] [   2691]   107  2691    11282 43   
126976   71  -900 dbus-daemon
[Tue Mar 22 00:24:10 2022] [   2729] 0  2729    62560 312   
135168   87 0 rsyslogd
[Tue Mar 22 00:24:10 2022] [   2731] 0  2731 9495 28   
114688   89 0 systemd-logind
[Tue Mar 22 00:24:10 2022] [   2730] 0  2730 6998 17    
98304   44 0 cron
[Tue Mar 22 00:24:10 2022] [   3025] 0  3025    20295 27   
135168  172 0 master
[Tue Mar 22 00:24:10 2022] [   3029]   101  3029    20824 26   
163840  170 0 qmgr
[Tue Mar 22 00:24:10 2022] [  13677]   101 13677    20812 192   
155648    0 0 pickup
[Tue Mar 22 00:24:10 2022] [   2915] 0  2915    17488 30   
176128  162 -1000 sshd
[Tue Mar 22 00:24:10 2022] [   2762] 0  2762 3164 0    
65536   32 0 agetty
[Tue Mar 22 00:24:10 2022] [   2761] 0  2761 3164 1    
69632   32 0 agetty
[Tue Mar 22 00:24:10 2022] [   2763] 0  2763 3164 1    
73728   31 0 agetty
[Tue Mar 22 00:24:10 2022] [  21053] 0 21053 1069 17    
53248    0 0 apt.systemd.dai
[Tue Mar 22 00:24:10 2022] [  21057] 0 21057 1069 31    
53248    0 0 apt.systemd.dai
[Tue Mar 22 00:24:10 2022] [  21065] 0 21065    17753 2552   
180224    0 0 apt-get
[Tue Mar 22 00:24:10 2022] [  21068] 0 21068 9475 110   
110592    0 0 systemd-journal
[Tue Mar 22 00:24:10 2022] 
oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=ns,mems_allowed=0-1,oom_memcg=/lxc/101,task_memcg=/lxc/101/ns,task=apt-get,pid=21065,uid=0
[Tue Mar 22 00:24:10 2022] Memory cgroup out of memory: Killed process 
21065 (apt-get) total-vm:71012kB, anon-rss:10208kB, file-rss:0kB, 
shmem-rss:0kB, UID:0 pgtables:176kB oom_score_adj:0
[Tue Mar 22 00:24:10 2022] oom_reaper: reaped process 21065 (apt-get), 
now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB


On 22/03/2022 14:55, Adam Weremczuk wrote:


Hi all,

I run a tiny and lightweight Debian 9.9 LXC container on Proxmox 6.2-6.

It has 512 MB of memory and 512 MB of swap assigned and typically 
needs 50-100 MB to operate.


Last year I started seeing about half of swap being used with very 
little use of RAM.


I then made the following changes:

/etc/sysctl.d/60-my-swappiness.conf
vm.swappiness=10

/etc/sysctl.conf
vm.swappiness=10

and rebooted.

The container was running like that for several months until this 
morning when its core service (dhcp) started failing.


I logged in to investigate and noticed 100% of swap being used with 
maybe 10-20% of RAM in use.


Before I had time to look into details the container crashed (powered 
off).


I'll probably try to get rid of swap entirely as an experiment to see 
what happens.


Unless somebody has any better ideas and hints?

Regards,
Adam

Re: swap maxed out when plenty of RAM available

[Nathanael Schweers]

Adam Weremczuk  writes:

> The container was running like that for several months until this morning 
> when its core service (dhcp) started failing.

Just a wild guess, but do you know what caused dhcp to fail?  Was it too
little memory?
>
> I logged in to investigate and noticed 100% of swap being used with maybe 
> 10-20% of RAM in use.

If I recall correctly, Linux may choose to swap pages out in order to
free up physical memory in order to use said memory for buffers and
caches.  This is a performance optimization.  So if there are pages
which have not been touched for a while, but I/O performance might
benefit from a larger cache, this is actually good for performance.

Regards,
Nathanael

Re: swap maxed out when plenty of RAM available

[Charles Kroeger]

I use

dphys-swapfile

this is a system service that auto configures a swap at boot without
requiring a static partition.

it computes the size of an optimal swap file and or resizes an existing
swap file if necessary. it mounts, dismounts, and deletes the swap if not
wanted. it doesn't dynamically resize swap during runtime.

-- 
pa'lante 

Re: swap maxed out when plenty of RAM available

[David Christensen]

On 3/22/22 07:55, Adam Weremczuk wrote:

Hi all,

I run a tiny and lightweight Debian 9.9 LXC container on Proxmox 6.2-6.

It has 512 MB of memory and 512 MB of swap assigned and typically needs 
50-100 MB to operate.


Last year I started seeing about half of swap being used with very 
little use of RAM.


I then made the following changes:

/etc/sysctl.d/60-my-swappiness.conf
vm.swappiness=10

/etc/sysctl.conf
vm.swappiness=10

and rebooted.

The container was running like that for several months until this 
morning when its core service (dhcp) started failing.


I logged in to investigate and noticed 100% of swap being used with 
maybe 10-20% of RAM in use.


Before I had time to look into details the container crashed (powered off).

I'll probably try to get rid of swap entirely as an experiment to see 
what happens.


Unless somebody has any better ideas and hints?

Regards,
Adam



Debian 9.9 is out of date.  Please update/ upgrade the LXC container to 
Debian 9.13.



If problems persist, please post console sessions with relevant details 
for the host machine (Proxmox hypervisor), the LXC container, and a DHCP 
client when the LXC container DHCP service is malfunctioning.



David

Re: swap maxed out when plenty of RAM available

[Greg Wooledge]

On Tue, Mar 22, 2022 at 04:00:23PM -0400, Kenneth Parker wrote:
> On Tue, Mar 22, 2022 at 2:17 PM Greg Wooledge  wrote:
> 
> > On Tue, Mar 22, 2022 at 01:00:42PM -0500, Nicholas Geovanis wrote:
> > > That's the usual issue. The /tmp filesystem is usually configured to live
> > > in RAM,
> >
> > That's not the default in Debian.  Of course, it might have been set up
> > that way on the OP's system.
> >
> 
> 
> This is an education for me.  You are quite right that /tmp is not in
> tmpfs, but other things are, including /dev/shm, which has the same,
> "liberal" permissions as /tmp.
> 
> So where *does* /tmp reside?

Depends on how you partition things during the installation.  It could
be a separate file system on disk, or just a plain old directory inside
the root file system.

The "default" (as far as that term has any meaning) is to be a plain old
directory.

Re: swap maxed out when plenty of RAM available

[Kenneth Parker]

On Tue, Mar 22, 2022 at 2:17 PM Greg Wooledge  wrote:

> On Tue, Mar 22, 2022 at 01:00:42PM -0500, Nicholas Geovanis wrote:
> > That's the usual issue. The /tmp filesystem is usually configured to live
> > in RAM,
>
> That's not the default in Debian.  Of course, it might have been set up
> that way on the OP's system.
>


This is an education for me.  You are quite right that /tmp is not in
tmpfs, but other things are, including /dev/shm, which has the same,
"liberal" permissions as /tmp.

So where *does* /tmp reside?

Thank you,

Kenneth Parker

Re: swap maxed out when plenty of RAM available

[Greg Wooledge]

On Tue, Mar 22, 2022 at 01:00:42PM -0500, Nicholas Geovanis wrote:
> That's the usual issue. The /tmp filesystem is usually configured to live
> in RAM,

That's not the default in Debian.  Of course, it might have been set up
that way on the OP's system.

> at some point an application needed to use lots of it. It may not have
> freed it properly
> from dying or maybe it's still running, or just misbehaving :-)

When an application terminates, all of the memory that it used for
private variables and such gets freed, and becomes available to other
processes.  However, this doesn't cause swapped-out pages belonging
to other processes to be swapped back in.  So, for example, immediately
after closing a web browser that was using gobs and gobs of memory, you
might see that the "used" memory drops dramatically, and "free" memory
grows.  But the amount of swap being used won't change immediately.

Swap space is used primarily (or ideally) by *inactive* processes.  It
won't be released until one of those processes wakes up and needs the
data that has been swapped out.  Or until one of those inactive
processes terminates, at which point all of its swap usage is released.

(When swap is used by an *active* process, that's called thrashing.  At
that point, you're in trouble.)

Re: swap maxed out when plenty of RAM available

[Nicholas Geovanis]

On Tue, Mar 22, 2022 at 12:21 PM Dan Ritter  wrote:

> Charles Curley wrote:
> > On Tue, 22 Mar 2022 14:55:34 +
> > Adam Weremczuk  wrote:
> >
> > > It has 512 MB of memory and 512 MB of swap assigned and typically
> > > needs 50-100 MB to operate.
> >
> > The rule of thumb to which I am accustomed is to have a swap space
> > double the physical RAM. If necessary, you can create a swap file and
> > add that to your /etc/fstab. That might help with your current problem.
> .
> That said, there is probably something else going on here. Logs
> on a tmpfs, maybe?
>

That's the usual issue. The /tmp filesystem is usually configured to live
in RAM,
at some point an application needed to use lots of it. It may not have
freed it properly
from dying or maybe it's still running, or just misbehaving :-)
If this happens often, consider building a larger /tmp in a real filesystem
on a real drive.


> -dsr-
>
>

Re: swap maxed out when plenty of RAM available

[Dan Ritter]

Charles Curley wrote: 
> On Tue, 22 Mar 2022 14:55:34 +
> Adam Weremczuk  wrote:
> 
> > It has 512 MB of memory and 512 MB of swap assigned and typically
> > needs 50-100 MB to operate.
> 
> The rule of thumb to which I am accustomed is to have a swap space
> double the physical RAM. If necessary, you can create a swap file and
> add that to your /etc/fstab. That might help with your current problem.

In the other direction, I would recommend removing swap and
reducing RAM to 256MB. For a service like DHCPd, it's better to
fail and restart than to just try to eat all available memory.
Then set vm.overcommit_memory=2 in sysctl to enforce that rather
than OOMd.

That said, there is probably something else going on here. Logs
on a tmpfs, maybe? 

-dsr-

Re: swap maxed out when plenty of RAM available

[Greg Wooledge]

On Tue, Mar 22, 2022 at 10:35:40AM -0600, Charles Curley wrote:
> On Tue, 22 Mar 2022 14:55:34 +
> Adam Weremczuk  wrote:
> 
> > It has 512 MB of memory and 512 MB of swap assigned and typically
> > needs 50-100 MB to operate.
> 
> The rule of thumb to which I am accustomed is to have a swap space
> double the physical RAM. If necessary, you can create a swap file and
> add that to your /etc/fstab. That might help with your current problem.

All those rules of thumb are crap.  They assume so many things that
you just can't assume.

If a system is filling up swap, that means that *at some point* there
was enough simultaneous memory demand from applications to require
filling up swap.  That memory demand might not exist *right now*, but
at some point, it did.  This might mean it's likely to occur again.
Or maybe it was a one-time thing.  Who can say?  Only the person whose
system it is.

The OP is going to need to gather a lot more data, unless they can
remember something like "Oh wait, I compiled emacs on this system the
other day; maybe that used a lot of memory."  Maybe set up a service
to run "vmstat 5" at boot and redirect it to a file.  Then if the full
swap partition is observed again, they can look at this file and at
least get an estimated timeframe for when the high memory use occurred,
and some supporting data.  There may be better tools, but vmstat is
the first one I can think of.

Re: swap maxed out when plenty of RAM available

[Charles Curley]

On Tue, 22 Mar 2022 14:55:34 +
Adam Weremczuk  wrote:

> It has 512 MB of memory and 512 MB of swap assigned and typically
> needs 50-100 MB to operate.

The rule of thumb to which I am accustomed is to have a swap space
double the physical RAM. If necessary, you can create a swap file and
add that to your /etc/fstab. That might help with your current problem.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

swap maxed out when plenty of RAM available

[Adam Weremczuk]

Hi all,

I run a tiny and lightweight Debian 9.9 LXC container on Proxmox 6.2-6.

It has 512 MB of memory and 512 MB of swap assigned and typically needs 
50-100 MB to operate.


Last year I started seeing about half of swap being used with very 
little use of RAM.


I then made the following changes:

/etc/sysctl.d/60-my-swappiness.conf
vm.swappiness=10

/etc/sysctl.conf
vm.swappiness=10

and rebooted.

The container was running like that for several months until this 
morning when its core service (dhcp) started failing.


I logged in to investigate and noticed 100% of swap being used with 
maybe 10-20% of RAM in use.


Before I had time to look into details the container crashed (powered off).

I'll probably try to get rid of swap entirely as an experiment to see 
what happens.


Unless somebody has any better ideas and hints?

Regards,
Adam

Re: Which flavour for a 2GB RAM laptop?

[Andrew M.A. Cater]

On Mon, Mar 07, 2022 at 04:06:01PM +0900, 황병희 wrote:
> Ottavio Caruso  writes:
> 
> > One of my memory slot has died, so I am running a Thinkpad with 2GB
> > ram only. I have been told that, even if I put a 4GB ram module in, it
> > won't be as fast as 2x2GB ram (true? Stop me here if I am
> > wrong). Never mind put an 8GB stick; it might not even work.
> >
> > At the moment I'm running a heavily hacked LMDE4 (Buster) with a lot
> > of Mint customisations off. What flavour of Debian should I replace my 
> > LMDE4 with? And does it make any difference? My memory hogs are
> > Chromium and Firefox, the rest is ok.
> 
> Hi, grazie!
> 
> My 1st chromebook(codename: alex)[0] have only 2GB ram. At that time
> (in 2016), i did install Ubuntu 12.04 LTS via Crouton[1] at there the
> chromebook. It was not bad.
> 
> So if you want Debian, Jessie (stable)[2] seems proper to you, i guess. 
> (also it would be good to try xfce ho ho ho ^^^)
> 

XFCE / Mate or Cinnamon all work on my Lenovo Ideapad with 32G disk and 2G RAM.
Web browsing may be a little slower using Firefox - don't open too many tabs.
This with Bullseye (Debian 11).

Please don't use Jessie at this point: it's almost entirely out of support by
anybody. Consider using something completely up to date.

With every good wish, as ever,

Andy Cater


> REFERENCE: [0-2]
> [0]
> <https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/samsung-series-5-chromebook/>
> [1] <https://github.com/dnschneid/crouton>
> [2] <https://wiki.debian.org/DebianJessie>
> 
> Sincerely, Linux fan Byung-Hee
> 
> -- 
> ^고맙습니다 _地平天成_ 감사합니다_^))//
> 

Re: Which flavour for a 2GB RAM laptop?

[황병희]

Ottavio Caruso  writes:

> One of my memory slot has died, so I am running a Thinkpad with 2GB
> ram only. I have been told that, even if I put a 4GB ram module in, it
> won't be as fast as 2x2GB ram (true? Stop me here if I am
> wrong). Never mind put an 8GB stick; it might not even work.
>
> At the moment I'm running a heavily hacked LMDE4 (Buster) with a lot
> of Mint customisations off. What flavour of Debian should I replace my 
> LMDE4 with? And does it make any difference? My memory hogs are
> Chromium and Firefox, the rest is ok.

Hi, grazie!

My 1st chromebook(codename: alex)[0] have only 2GB ram. At that time
(in 2016), i did install Ubuntu 12.04 LTS via Crouton[1] at there the
chromebook. It was not bad.

So if you want Debian, Jessie (stable)[2] seems proper to you, i guess. 
(also it would be good to try xfce ho ho ho ^^^)

REFERENCE: [0-2]
[0]
<https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/samsung-series-5-chromebook/>
[1] <https://github.com/dnschneid/crouton>
[2] <https://wiki.debian.org/DebianJessie>

Sincerely, Linux fan Byung-Hee

-- 
^고맙습니다 _地平天成_ 감사합니다_^))//

Re: Which flavour for a 2GB RAM laptop?

[David Christensen]

On 3/5/22 02:10, Ottavio Caruso wrote:

On 05/03/2022 00:56, David Christensen wrote:

On 3/4/22 02:47, Ottavio Caruso wrote:
One of my memory slot has died, 



I would retire that computer.


Thanks. Where do I send my bank details for the funding of a new laptop?




so I am running a Thinkpad 



What model/ part number is the Thinkpad?



$ inxi -F && sudo inxi -m
System:    Host: e130 Kernel: 4.19.0-17-amd64 x86_64 bits: 64 Desktop: 
MATE 1.20.4 Distro: LMDE 4 Debbie
Machine:   Type: Laptop System: LENOVO product: 33588QG v: ThinkPad Edge 
E130 serial: 
    Mobo: LENOVO model: 33588QG v: Win8 Pro DPK TPG serial: 
 UEFI: LENOVO v: H4ET98WW (2.58 )

    date: 08/24/2016
Battery:   ID-1: BAT1 charge: 34.3 Wh condition: 57.6/62.2 Wh (93%)
CPU:   Topology: Dual Core model: Intel Core i3-3217U bits: 64 type: 
MT MCP L2 cache: 3072 KiB
    Speed: 798 MHz min/max: 800/1800 MHz Core speeds (MHz): 1: 
798 2: 798 3: 798 4: 798
Graphics:  Device-1: Intel 3rd Gen Core processor Graphics driver: i915 
v: kernel
    Display: x11 server: X.Org 1.20.4 driver: modesetting 
unloaded: fbdev,vesa resolution: 1366x768~60Hz
    OpenGL: renderer: Mesa DRI Intel Ivybridge Mobile v: 4.2 
Mesa 18.3.6
Audio: Device-1: Intel 7 Series/C216 Family High Definition Audio 
driver: snd_hda_intel

    Sound Server: ALSA v: k4.19.0-17-amd64
Network:   Device-1: Intel Centrino Wireless-N 2230 driver: iwlwifi
    IF: wlp3s0 state: up mac: 84:a6:c8:a8:de:be
    Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit 
Ethernet driver: r8169

    IF: enp9s0 state: down mac: 08:9e:01:35:89:ce
    Device-3: Ericsson Business Mobile Networks BV H5321 gw 
Mobile Broadband Driver type: USB

    driver: cdc_acm,cdc_ncm,cdc_wdm
    IF: wwp0s29u1u6i6 state: down mac: 02:15:e0:ec:01:00
Drives:    Local Storage: total: 465.76 GiB used: 285.99 GiB (61.4%)
    ID-1: /dev/sda vendor: Hitachi model: HTS725050A7E630 size: 
465.76 GiB
Partition: ID-1: / size: 47.81 GiB used: 17.35 GiB (36.3%) fs: ext4 dev: 
/dev/sda5
    ID-2: /home size: 46.45 GiB used: 26.20 GiB (56.4%) fs: ext4 
dev: /dev/sda8
    ID-3: swap-1 size: 8.08 GiB used: 164.6 MiB (2.0%) fs: swap 
dev: /dev/sda7

Sensors:   System Temperatures: cpu: 47.0 C mobo: 0.0 C
    Fan Speeds (RPM): cpu: 598
Info:  Processes: 167 Uptime: 15h 46m Memory: 1.73 GiB used: 899.0 
MiB (50.8%) Shell: bash inxi: 3.0.32

Memory:    RAM: total: 1.73 GiB used: 898.5 MiB (50.7%)
    Array-1: capacity: 16 GiB slots: 2 EC: None
    Device-1: ChannelA-DIMM0 size: No Module Installed
    Device-2: ChannelB-DIMM0 size: 2 GiB speed: 1333 MT/s



Is the Lenovo ThinkPad Edge E130 your one and only computer?  If and 
when the other memory socket goes bad, you will be in a tough situation. 
 It would be better to get a working computer now, install Debian, 
migrate your data, and then recycle the E130.



Used equipment is a much better value than new equipment.  I prefer 
computers with Xeon processors, integrated graphics, and ECC memory.



Rack mount servers can be found on eBay starting around US$100 (you 
provide the HDD/SSD and Debian):


https://www.ebay.com/sch/175698/i.html?_nkw=xeon+ecc&_sop=15


Entry-level tower servers with Xeon E3 v5 processors and Intel 
integrated graphics start around US$200, and also work well as desktop 
machines (again, you provide the HDD/SSD and Debian):


https://www.ebay.com/sch/i.html?_nkw=xeon+e3-1225+v5+tower&_sop=15


David

Re: Which flavour for a 2GB RAM laptop?

[tomas]

On Sat, Mar 05, 2022 at 10:03:44AM +, Ottavio Caruso wrote:
> On 04/03/2022 14:13, to...@tuxteam.de wrote:
> > Or just ditch the desktop environment altogether and use a
> > honest window manager (e.g. Fvwm
> 
> Is it still around? I used to use it circa 2003...

Yes, of course. It's distributed with Debian. Doesn't change very
much (for me an asset). It does what it has to, I can configure
it as I want -- what's not to like?

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Which flavour for a 2GB RAM laptop?

[David Christensen]

On 3/4/22 02:47, Ottavio Caruso wrote:
One of my memory slot has died, 



I would retire that computer.


so I am running a Thinkpad 



What model/ part number is the Thinkpad?

What make/ model/ part number is the processor?

What make/ model/ part number are the hard disk(s) and/or solid state 
drives?



with 2GB ram only. 



What make/ model/ part number are the memory module(s)?


I have been told that, even if I put a 4GB ram module in, it won't 
be as fast as 2x2GB ram (true? Stop me here if I am wrong). 



If the motherboard, chipset, CPU, GPU, etc., support multiple memory 
channels ("dual channel" is common) and you install the correct memory 
modules (e.g. "matched pair"), connected hardware will be able to access 
memory banks in parallel and the computer will perform better (less 
latency, more throughput) .  You want that; the effect is noticeable.




Never mind put an 8GB stick; it might not even work.



The technical manual for your computer should tell you what memory 
modules are supported.  As another reader suggested, you might want to 
"max it out" by installing the biggest, fastest supported memory modules 
in every available memory slot.



At the moment I'm running a heavily hacked LMDE4 (Buster) with a lot of 
Mint customisations off. What flavour of Debian should I replace my 
LMDE4 with? And does it make any difference? My memory hogs are Chromium 
and Firefox, the rest is ok.



I recommend the network install image of Debian Stable:

https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/

debian-11.2.0-amd64-netinst.iso


Be sure to download a checksum file (e.g. SHA256SUMS) and verify the 
checksum of the ISO file after downloading.  If you want to be extra 
careful, download the checksum signature file (e.g. SHA256SUMS.sign) and 
verify the signature.



Burn the ISO to a fast USB flash drive.  Verify the checksum of the 
burned image before booting (one booted, the Debian installer may write 
to the USB flash drive and the checksum will no longer match).



If you select "Install" at the Debian Installer main menu, you should be 
able to choose among various desktop environments (I run Xfce).  If you 
select "expert", you should have even more control.  It is also possible 
to install additional login managers, window managers, desktop 
environments, etc., at a later time.



David

Re: Which flavour for a 2GB RAM laptop?

[Nicholas Geovanis]

On Fri, Mar 4, 2022 at 4:58 AM Christian Britz  wrote:

>
> On 2022-03-04 11:47 UTC+0100, Ottavio Caruso wrote:
> > One of my memory slot has died, so I am running a Thinkpad with 2GB ram
> > only. I have been told that, even if I put a 4GB ram module in, it won't
> > be as fast as 2x2GB ram (true? Stop me here if I am wrong). Never mind
> > put an 8GB stick; it might not even work.
>
> As far as I know this depends on the design / architecture of the
> chipset / motherboard.
>

More specifically, get ahold of the doc for your specific model of
Thinkpad. Lenovo/IBM are better than
average for making it available online. There will be a short section on
RAM configuration.
In general, using interleaving across "banks" should be done with sticks at
identical design frequencies
and sizes. But often there you have a choice of interleaving style.


> > At the moment I'm running a heavily hacked LMDE4 (Buster) with a lot of
> > Mint customisations off. What flavour of Debian should I replace my
> > LMDE4 with? And does it make any difference? My memory hogs are Chromium
> > and Firefox, the rest is ok.
> You should run Debian stable for daily use. If performance is your main
> concern, try one of the light desktop environments (Xfce, LXDE,
> LXQT...). I like the simplicity of LXQT, although I have recently fallen
> in love with Cutefish (not yet in Debian).
>
> Regards,
> Christian
>
> --
> http://www.cb-fraggle.de
>
>

Re: Which flavour for a 2GB RAM laptop?

[Christian Britz]

On 2022-03-04 16:10 UTC+0100, Hans wrote:

> There are also other WM available, which may be faster, like fvwm95, openbox, 
> twm.
amiwm ;-)

-- 
http://www.cb-fraggle.de

Re: Which flavour for a 2GB RAM laptop?

[Hans]

I am a great fan of my old EEEPC, beecause it is tiny and running a long time.

But it is 32-bit, not fast, although I spent him 2GB fast RAM and a SSD.

So I tested with several window managers. There was no number 1 winner, but 
IMO the fastest one was LXDE. Almsot the same speed gave me XFCE (which has a 
little advantage, that it can look like Windows_10).

As LXDE is no more developed, I tries its sucessor, LXQT (a conglomerat of 
RazorQT ans LXDE), which was amazingly just as fast as XFCE (but slower than 
it), but is looking more comfortable than LXDE or XFCE.

Gnome I never tested, because I do not like it personally, but I tested 
Plasma5 (former KDE), and it was still ruunning smooth on my slow netbook. 

However, in Plasma5 I noticed, that the bottom bar is flickering, when I hover 
the mouse over it. This appeared after an update about 2 years ago (guess, 
they changed some code, so it got slower). As this is not a bug at all, I did 
never file it.

So, that is the tests I did. 

How in practice? Well, when I am on the road, I am using often a livefile 
system (here: kali-linux) or the native installed system (here: debian/
bullseye 32-bit), and when I need speed, LXDE ist my first choice, especially 
when running kali. 

For my normal work, when speed does not matter, I am using either LXQT or , 
for comfort and a I am a dinosaur, Plasma5 (you can well work with it, it is 
just 10 percent slower than XFCE).

Conclusion:

If speed is most important: LXDE (maybe sometimes no more available)

If speed is most important and you need Windows_10 look: XFCE

If a good relation between speed and comfort: LXQT

If comfort and some flickering does not matter: Plasma5

There are also other WM available, which may be faster, like fvwm95, openbox, 
twm.

And last but not least, there is TRINITY, which is a modern build of KDE3 (or 
4???), which is running fast and has great comfort.

However, it is not in the debian repo, and it does interfere with Plasma5, but 
it is worth a look. I ran it a while on my EEEPC, but it got interfered with 
Plasma5 (especially kmail), so I deinstalled it. But if you do not want 
install Plasma5, try TRINITY.

Hope this helps!

Best regards

Hans

  



 

Re: Which flavour for a 2GB RAM laptop?

[tomas]

On Fri, Mar 04, 2022 at 05:56:50AM -0800, Peter Ehlert wrote:

[...]

> I keep hearing about Xfce being "light"
> 
> it defiantly is, but I decided to compare it to my personal favorite Mate
> 
> Two fresh netinstalls, same machine, same SSD drive. Xfce and Mate desktops
> 
> xfce:  774 MIB ram used .. 4 GIB / space used
> mate:  719 MIB ram used .. 6 GIB / space used
> mate*:  722 MIB ram used .. 6 GIB / space used
> 
> *Mate with the mate-desktop-environment-extras metapackage

Or just ditch the desktop environment altogether and use a
honest window manager (e.g. Fvwm ;-)

USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
[...]
root  1867  0.0  0.0   8460  2096 ?Ss   Mar03   0:00 /usr/bin/xdm
root  1885  0.8  0.3 758372 55104 tty7 Ssl+ Mar03  10:24  \_ 
/usr/lib/xorg/Xorg :0 vt7 -nolisten tcp -auth 
/var/lib/xdm/authdir/authfiles/A:0-QCuTrm
root  2088  0.0  0.0  16052  8228 ?Ss   Mar03   0:00  \_ -:0
tomas 2433  0.0  0.0  80564 14812 ?Ss   Mar03   0:05  \_ 
x-window-manager
tomas 2484  0.0  0.0   5964  2692 ?Ss   Mar03   0:00  \_ 
/usr/bin/ssh-agent x-window-manager
tomas 2485  0.0  0.0   5612  1324 ?SMar03   0:00  \_ 
/usr/lib/fvwm/2.6.8/FvwmCommandS 8 5 /home/tomas/.fvwm/config 0 8
tomas 2486  0.0  0.0  76212 11384 ?SMar03   0:00  \_ 
/usr/lib/fvwm/2.6.8/FvwmButtons 10 5 /home/tomas/.fvwm/config 0 8
tomas 2487  0.0  0.0  76184 12340 ?SMar03   0:00  \_ 
/usr/lib/fvwm/2.6.8/FvwmPager 11 4 none 0 8 0 0

Yes, that's 15 MB RSS for the window manager, roughly 45 MB counting
in its minions :-)

That's less than one-tenth of one of the many firefox's sprawling
tentacles...

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Which flavour for a 2GB RAM laptop?

[Eric S Fraga]

On Friday,  4 Mar 2022 at 05:56, Peter Ehlert wrote:
> xfce:  774 MIB ram used .. 4 GIB / space used
> mate:  719 MIB ram used .. 6 GIB / space used
> mate*:  722 MIB ram used .. 6 GIB / space used

stumpwm: 86 MB, 1.3 GB ;-)

-- 
Eric S Fraga with org 9.5.2 in Emacs 29.0.50 on Debian 11.2

Re: Which flavour for a 2GB RAM laptop?

[Peter Ehlert]

On 3/4/22 02:58, Christian Britz wrote:


On 2022-03-04 11:47 UTC+0100, Ottavio Caruso wrote:

One of my memory slot has died, so I am running a Thinkpad with 2GB ram
only. I have been told that, even if I put a 4GB ram module in, it won't
be as fast as 2x2GB ram (true? Stop me here if I am wrong). Never mind
put an 8GB stick; it might not even work.

As far as I know this depends on the design / architecture of the
chipset / motherboard.


At the moment I'm running a heavily hacked LMDE4 (Buster) with a lot of
Mint customisations off. What flavour of Debian should I replace my
LMDE4 with? And does it make any difference? My memory hogs are Chromium
and Firefox, the rest is ok.

You should run Debian stable for daily use. If performance is your main
concern, try one of the light desktop environments (Xfce, LXDE,
LXQT...).


I keep hearing about Xfce being "light"

it defiantly is, but I decided to compare it to my personal favorite Mate

Two fresh netinstalls, same machine, same SSD drive. Xfce and Mate desktops

xfce:  774 MIB ram used .. 4 GIB / space used
mate:  719 MIB ram used .. 6 GIB / space used
mate*:  722 MIB ram used .. 6 GIB / space used

*Mate with the mate-desktop-environment-extras metapackage

I did not stress test either but the apparent speed was the same


I like the simplicity of LXQT, although I have recently fallen
in love with Cutefish (not yet in Debian).

Regards,
Christian

Re: Which flavour for a 2GB RAM laptop?

[Richard Owlett]

On 03/04/2022 04:47 AM, Ottavio Caruso wrote:
One of my memory slot has died, so I am running a Thinkpad with 2GB ram 


I suspect the specific model of Thinkpad may be relevant.
HTH

only. I have been told that, even if I put a 4GB ram module in, it won't 
be as fast as 2x2GB ram (true? Stop me here if I am wrong). Never mind 
put an 8GB stick; it might not even work.


At the moment I'm running a heavily hacked LMDE4 (Buster) with a lot of 
Mint customisations off. What flavour of Debian should I replace my 
LMDE4 with? And does it make any difference? My memory hogs are Chromium 
and Firefox, the rest is ok.


Thanks, merci, grazie.

Re: Which flavour for a 2GB RAM laptop?

[Christian Britz]

On 2022-03-04 11:47 UTC+0100, Ottavio Caruso wrote:
> One of my memory slot has died, so I am running a Thinkpad with 2GB ram 
> only. I have been told that, even if I put a 4GB ram module in, it won't 
> be as fast as 2x2GB ram (true? Stop me here if I am wrong). Never mind 
> put an 8GB stick; it might not even work.

As far as I know this depends on the design / architecture of the
chipset / motherboard.

> At the moment I'm running a heavily hacked LMDE4 (Buster) with a lot of 
> Mint customisations off. What flavour of Debian should I replace my 
> LMDE4 with? And does it make any difference? My memory hogs are Chromium 
> and Firefox, the rest is ok.
You should run Debian stable for daily use. If performance is your main
concern, try one of the light desktop environments (Xfce, LXDE,
LXQT...). I like the simplicity of LXQT, although I have recently fallen
in love with Cutefish (not yet in Debian).

Regards,
Christian

-- 
http://www.cb-fraggle.de

Re: Missing some RAM?

[local10]

Aug 3, 2021, 10:56 by s...@svenhartge.de:

> So in the end, we have 2812MB + 4846MB = 7658MB (approx) usable for the
> system as a whole. The Kernel and it data structures also take some of
> this, so to have ~7400MB as usable memory is not unreasonable.
>


Thanks for the explanation. 

Re: Missing some RAM?

[Sven Hartge]

local10  wrote:

>  BIOS-e820: [mem 0x-0x0009c7ff] usable
>  BIOS-e820: [mem 0x0009f800-0x0009] reserved
>  BIOS-e820: [mem 0x000f-0x000f] reserved
>  BIOS-e820: [mem 0x0010-0xafde] usable
>  BIOS-e820: [mem 0xafdf-0xafdf2fff] ACPI NVS
>  BIOS-e820: [mem 0xafdf3000-0xafdf] ACPI data
>  BIOS-e820: [mem 0xafe0-0xafef] reserved
>  BIOS-e820: [mem 0xe000-0xefff] reserved
>  BIOS-e820: [mem 0xfec0-0x] reserved
>  BIOS-e820: [mem 0x0001-0x00022fff] usable
>  e820: update [mem 0x-0x0fff] usable ==> reserved
>  e820: remove [mem 0x000a-0x000f] usable
>  e820: update [mem 0xafe0-0xffff] usable ==> reserved
>  e820: reserve RAM buffer [mem 0x0009c800-0x0009]
>  e820: reserve RAM buffer [mem 0xafdf-0xafff]

Let's start from the back:

>  BIOS-e820: [mem 0x0001-0x00022fff] usable

This is the memory region from 4GB to 8GB and a bit of remapped memory
(or it would have ended at 0x0001).

So we have 4GB plus 805306368 Bytes (768MN) or 4846MB beyond the 4GB
32bit area.

Then we have this big reserved area:

>  BIOS-e820: [mem 0xafdf-0xafdf2fff] ACPI NVS
>  BIOS-e820: [mem 0xafdf3000-0xafdf] ACPI data
>  BIOS-e820: [mem 0xafe0-0xafef] reserved
>  BIOS-e820: [mem 0xe000-0xefff] reserved
>  BIOS-e820: [mem 0xfec0-0x] reserved

1344339968 Bytes or (roughly) 1282MB. The PCI memory area, ACPI tables,
DMA stuff, etc. are located here. 

Some of the physical memory shadowed by this will be in the 768MB of
memory from above.

Then we have a bit of usable memory again:

>  BIOS-e820: [mem 0x0010-0xafde] usable

2949578752 Bytes or roughly 2812MB.

And the rest is reserved or will be reserved, for example the lower 1MB
for security reasons:

>  BIOS-e820: [mem 0x-0x0009c7ff] usable
>  BIOS-e820: [mem 0x0009f800-0x0009] reserved
>  BIOS-e820: [mem 0x000f-0x000f] reserved
>  e820: update [mem 0x-0x0fff] usable ==> reserved
>  e820: remove [mem 0x000a-0x000f] usable
>  e820: update [mem 0xafe0-0x] usable ==> reserved

So in the end, we have 2812MB + 4846MB = 7658MB (approx) usable for the
system as a whole. The Kernel and it data structures also take some of
this, so to have ~7400MB as usable memory is not unreasonable.

S°

-- 
Sigmentation fault. Core dumped.

Re: Missing some RAM?

[local10]

Aug 3, 2021, 10:05 by s...@svenhartge.de:

> The PCI memory area is probably to blame here. Also the kernel needs
> some memory for itself.
>
> Please reboot your system and then, as root do:
>
>  dmesg | grep "e820"
>
> and post the output. That will tell us the memory map of your system and
> which regions are used or reserved.
>


#  dmesg | grep "e820"
[    0.00] BIOS-e820: [mem 0x-0x0009c7ff] usable
[    0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved
[    0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[    0.00] BIOS-e820: [mem 0x0010-0xafde] usable
[    0.00] BIOS-e820: [mem 0xafdf-0xafdf2fff] ACPI NVS
[    0.00] BIOS-e820: [mem 0xafdf3000-0xafdf] ACPI data
[    0.00] BIOS-e820: [mem 0xafe0-0xafef] reserved
[    0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[    0.00] BIOS-e820: [mem 0xfec0-0x] reserved
[    0.00] BIOS-e820: [mem 0x0001-0x00022fff] usable
[    0.005949] e820: update [mem 0x-0x0fff] usable ==> reserved
[    0.005951] e820: remove [mem 0x000a-0x000f] usable
[    0.014336] e820: update [mem 0xafe0-0x] usable ==> reserved
[    0.221537] Aperture pointing to e820 RAM. Ignoring.
[    0.438742] e820: reserve RAM buffer [mem 0x0009c800-0x0009]
[    0.438743] e820: reserve RAM buffer [mem 0xafdf-0xafff]

Thanks,

Re: Missing some RAM?

[Sven Hartge]

local10  wrote:

> The "why 1G memory is missing?" thread got me thinking. My PC also
> seems to be missing hundreds MB of RAM and that's how it's been for
> years. I have 4*2GB RAM boards so, in theory, I should've had 8GB of
> RAM but top shows only 7472.2MiB. Even after the MiB to MB conversion
> there's still some RAM missing: 7472.2 MiB = 7835.169 MB.

> Any ideas? Any way to get it back? Thanks

The PCI memory area is probably to blame here. Also the kernel needs
some memory for itself.

Please reboot your system and then, as root do:

  dmesg | grep "e820"

and post the output. That will tell us the memory map of your system and
which regions are used or reserved.

S°

-- 
Sigmentation fault. Core dumped.

Missing some RAM?

[local10]

Hi,

The "why 1G memory is missing?" thread got me thinking. My PC also seems to be 
missing hundreds MB of RAM and that's how it's been for years. I have 4*2GB RAM 
boards so, in theory, I should've had 8GB of RAM but top shows only 7472.2MiB. 
Even after the MiB to MB conversion there's still some RAM missing: 7472.2 MiB 
= 7835.169 MB.

Any ideas? Any way to get it back? Thanks


# top
...
MiB Mem :   7472.2 total,   1284.6 free,   2085.0 used,   4102.5 buff/cache
...

# echo "This is a Debian 10 Buster PC"; uname -a
This is a Debian 10 Buster PC
Linux rsvd 4.19.0-17-amd64 #1 SMP Debian 4.19.194-1 (2021-06-10) x86_64 
GNU/Linux

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[songbird]

Marco Möller wrote:
> On 10.03.21 19:28, Cmdte Alpha Tigre Z wrote:
> (...)
>> I don't think there is a Debian DVD iso I can use to install Debian 
>> Bullseye.
>> I think I'll have to install Buster and then switch to Bullseye.
>> Is there a better option?
>
> To my knowledge, there is a Bulleye installer available here:
> https://www.debian.org/devel/debian-installer/
> It is still a test version, but you have good chances that it will work 
> just fine. As described before, "testing" in Debian does not mean 
> "unstable". With some bad luck for you, you might find a bug in it. If 
> you could then report it, then luck for the Debian community because 
> someone found it and it can be corrected for pushing the installer a 
> step forward to soon become "stable".

  for the record, the daily images worked fine for me the other
day as i wanted to be sure the recent daily netinst image
would boot and get as far as partitioning on this new motherboard.
all that went ok.  i did not actually do any further installation
with it though because i have to do some resizing and moving of
partitions to set up a free spot to do a new install and i'm not
sure i really want to do that yet.  mainly i just wanted to make
sure i had a recent rescue image that would boot just in case my
future poking at UEFI things on this machine turns it into non-
functional.


  songbird

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[Cmdte Alpha Tigre Z]

> <http://trinitydesktop.org/>
> TDE is the only DE I use on my Debians. Light it is, but with a feature
set that
> floats my boat very well.
> I had only 2GB RAM on this old Core2Duo until recently:
>
> # free  # on fresh boot to multi-user.target
>   totalusedfree  shared  buff/cache
 available
> Mem:4040856  126748 37710602936  143048
 3722780
> Swap:   1903664   0 1903664
> # free  # after startx into TDE and Konsole
>   totalusedfree  shared  buff/cache
 available
> Mem:4040856  264720 35009243080  275212
 3552548
> Swap:   1903664   0 1903664
>  137972 used to get TDE session with Konsole
started
> # inxi -CGISy
> System:
>   Host: p5bse Kernel: 4.19.0-13-amd64 x86_64 bits: 64
>   Desktop: Trinity R14.0.10 Distro: Debian GNU/Linux 10 (buster)
> CPU:
>   Info: Dual Core model: Intel Core2 Duo E7500 bits: 64 type: MCP
>   L2 cache: 3 MiB
>   Speed: 1600 MHz min/max: 1596/2926 MHz Core speeds (MHz): 1: 1600 2:
1600
> Graphics:
>   Device-1: NVIDIA GF119 [NVS 310] driver: nouveau v: kernel
>   Display: server: X.Org 1.20.4 driver: loaded: modesetting
>   unloaded: fbdev,vesa resolution: 1920x1200~60Hz
>   OpenGL: renderer: NVD9 v: 4.3 Mesa 18.3.6

Thanks, I think I could try it on my mini laptop with 1 GB of RAM and an
Intel Atom N455 @ 1.66 GHz.

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[Felix Miata]

Cmdte Alpha Tigre Z composed on 2021-03-10 07:26 (UTC-0400):

> How is that TDE?  Is it like KDE but much lighter?
> What are the main differences?

<http://trinitydesktop.org/>
TDE is the only DE I use on my Debians. Light it is, but with a feature set that
floats my boat very well.
I had only 2GB RAM on this old Core2Duo until recently:

# free  # on fresh boot to multi-user.target
  totalusedfree  shared  buff/cache   available
Mem:4040856  126748 37710602936  143048 3722780
Swap:   1903664   0 1903664
# free  # after startx into TDE and Konsole
  totalusedfree  shared  buff/cache   available
Mem:4040856  264720 35009243080  275212 3552548
Swap:   1903664   0 1903664
 137972 used to get TDE session with Konsole started
# inxi -CGISy
System:
  Host: p5bse Kernel: 4.19.0-13-amd64 x86_64 bits: 64
  Desktop: Trinity R14.0.10 Distro: Debian GNU/Linux 10 (buster)
CPU:
  Info: Dual Core model: Intel Core2 Duo E7500 bits: 64 type: MCP
  L2 cache: 3 MiB
  Speed: 1600 MHz min/max: 1596/2926 MHz Core speeds (MHz): 1: 1600 2: 1600
Graphics:
  Device-1: NVIDIA GF119 [NVS 310] driver: nouveau v: kernel
  Display: server: X.Org 1.20.4 driver: loaded: modesetting
  unloaded: fbdev,vesa resolution: 1920x1200~60Hz
  OpenGL: renderer: NVD9 v: 4.3 Mesa 18.3.6
Info:...Shell: Bash inxi: 3.3.01
-- 
Evolution as taught in public schools, like religion,
is based on faith, not on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[Andrei POPESCU]

On Mi, 10 mar 21, 16:55:39, Cmdte Alpha Tigre Z wrote:
> 
> Sorry, I wasn't clear: first Buster then Bullseye. That way I will stay on
> Bullseye
> when it becomes "stable". I think it will happen soon, won't it?

It's a few months away, which in Debian's timeline is indeed soon ;)

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[Cmdte Alpha Tigre Z]

> Be aware that although testing has less churn than unstable, that also
means that when a bug does creep through, it may take a week or two to see
the next release of the software, whereas unstable might see the fix come
in later that same day.
>
> It's a trade-off.

Sorry, I wasn't clear: first Buster then Bullseye. That way I will stay on
Bullseye
when it becomes "stable". I think it will happen soon, won't it?

Anyway, thanks for your remark.

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[Kent West]

On Wed, Mar 10, 2021 at 1:42 PM Cmdte Alpha Tigre Z 
wrote:

>
> Thanks.  I think I would rather prefer non-free software as a second
> option.
>
> Since I'm new to this, I would prefer to go the safe way: first Debian
> 10, then testing.
>
>
Be aware that although testing has less churn than unstable, that also
means that when a bug does creep through, it may take a week or two to see
the next release of the software, whereas unstable might see the fix come
in later that same day.

It's a trade-off.


-- 
Kent West<")))><
Westing Peacefully - http://kentwest.blogspot.com

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[Cmdte Alpha Tigre Z]

> To my knowledge, there is a Bulleye installer available here:
> https://www.debian.org/devel/debian-installer/
> It is still a test version, but you have good chances that it will work
> just fine. As described before, "testing" in Debian does not mean
> "unstable". With some bad luck for you, you might find a bug in it. If
> you could then report it, then luck for the Debian community because
> someone found it and it can be corrected for pushing the installer a
> step forward to soon become "stable".
>
> Well, not the best answer for being on the Debian mailing list, but if
> you are entirely new to Debian or even Linux then it could be a good
> option to start with the distribution Sparky Linux (there is a KDE
> Edition available) for getting up and running and obtaining insides into
> many available options and learning about the usage of the apt package
> manager and other tools. Sparky Linux is not Debian, because it has some
> fine extras for making it much easier accessible to new Linux users. But
> there is so much Debian under the hood, which is configured so close to
> the original Debian, that I recommend it for entirely new Linux users.
> It is the Debian derivative being closest to Debian of all Debian
> derivatives I would know of. It comes with easy options to install
> almost any desktop environment around. Use it for testing and getting up
> and running, and you are of course free to return to Debian after you
> already have a clear idea of what is good for you and your hardware.
> In the sense of the Debian community I advice that in Sparky Linux
> offered software is not all following the Debian software license policy
> concerning GNU/Linux and Open Source, because it also provides out of
> the box access to third party software installations which wouldn't have
> place in Debian.
>
> Good Luck!
> Marco.

Thanks.  I think I would rather prefer non-free software as a second option.

Since I'm new to this, I would prefer to go the safe way: first Debian
10, then testing.

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[Marco Möller]

On 10.03.21 19:28, Cmdte Alpha Tigre Z wrote:
(...)
I don't think there is a Debian DVD iso I can use to install Debian 
Bullseye.

I think I'll have to install Buster and then switch to Bullseye.
Is there a better option?


To my knowledge, there is a Bulleye installer available here:
https://www.debian.org/devel/debian-installer/
It is still a test version, but you have good chances that it will work 
just fine. As described before, "testing" in Debian does not mean 
"unstable". With some bad luck for you, you might find a bug in it. If 
you could then report it, then luck for the Debian community because 
someone found it and it can be corrected for pushing the installer a 
step forward to soon become "stable".


Well, not the best answer for being on the Debian mailing list, but if 
you are entirely new to Debian or even Linux then it could be a good 
option to start with the distribution Sparky Linux (there is a KDE 
Edition available) for getting up and running and obtaining insides into 
many available options and learning about the usage of the apt package 
manager and other tools. Sparky Linux is not Debian, because it has some 
fine extras for making it much easier accessible to new Linux users. But 
there is so much Debian under the hood, which is configured so close to 
the original Debian, that I recommend it for entirely new Linux users. 
It is the Debian derivative being closest to Debian of all Debian 
derivatives I would know of. It comes with easy options to install 
almost any desktop environment around. Use it for testing and getting up 
and running, and you are of course free to return to Debian after you 
already have a clear idea of what is good for you and your hardware.
In the sense of the Debian community I advice that in Sparky Linux 
offered software is not all following the Debian software license policy 
concerning GNU/Linux and Open Source, because it also provides out of 
the box access to third party software installations which wouldn't have 
place in Debian.


Good Luck!
Marco.

Re: Plasma can be a lightweight (was: Hardware requirements between Debian 9 and 10; and was also: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?)

[Cmdte Alpha Tigre Z]

On 10/03/2021 07:23, "Felix Miata"  wrote:
>
> Felix Miata composed on 2021-03-10 05:33 (UTC-0500):
>
> > Cmdte Alpha Tigre Z composed on 2021-03-09 19:00 (UTC-0400):
>
> >> I have been reading throughout the Web
> >> that Xfce4 is not so lightweight as it was before.
> >> Apparently, its performance is comparable to that of KDE
> >> or GNOME.
>
> > This may be where that came from:
> > <https://www.youtube.com/watch?v=RrvJOXypAbk>
>
> > Here's a simple look at RAM before and after first launching IceWM, then
> > rebooting, then a freshly installed Plasma session on an old single
core PC that
> > had had only KDE3 and IceWM on TW.
>
> > # inxi -CGIMy
> > Machine:
> >   Type: Desktop System: Dell product: OptiPlex GX280 v: N/A serial:
20HRT71
> >   Mobo: Dell model: N/A serial: .. . BIOS: Dell v: A07 date: 11/29/2005
> > CPU:
> >   Info: Single Core model: Intel Pentium 4 bits: 32 type: MCP L2 cache:
1024 KiB
> >   Speed: 2793 MHz min/max: N/A Core speed (MHz): 1: 2793
> > Graphics:
> >   Device-1: Intel 82915G/GV/910GL Integrated Graphics driver: i915 v:
kernel
> >   Display: x11 server: X.Org 1.20.10 driver: loaded: intel
> >   unloaded: fbdev,modesetting,vesa resolution: 1680x1050~60Hz
> >   OpenGL: renderer: Mesa DRI Intel 915G x86/MMX/SSE2 v: 1.4 Mesa 20.3.4
> > Info:...Shell: Bash inxi: 3.3.01
>
> > # free# before launching startx into IceWM
> >totalusedfree  shared  buff/cache
 available
> > Mem: 1525408   51264 13135801552  160564
 1293900
> > Swap:1036156   0 1036156
> > # free# after launching startx into IceWM and Xterm
> >totalusedfree  shared  buff/cache
 available
> > Mem: 1525408   71732 1213716   14980  239960
 1259048
> > Swap:1036156   0 1036156
> >  20468 used by IceWM
> > # inxi -Sy
> > System:
> >   Host: gx28b Kernel: 5.7.11-1-default i686 bits: 32
> >   Desktop: IceWM 2.1.1 Distro: openSUSE Tumbleweed 20210307
> >
> > I rebooted before launching Plasma and Konsole on the same PC:
> > # free# before launching startx into virgin Plasma
installation
> >totalusedfree  shared  buff/cache
 available
> > Mem: 1525568   51536 13056328444  168400
 1286812
> > Swap:1036156   0 1036156
> > # free# after launching startx into virgin Plasma
installation
> >totalusedfree  shared  buff/cache
 available
> > Mem: 1525568  188264  899976   51360  437328
 1103940
> > Swap:1036156   0 1036156
> > 136728
> > # inxi -Sy
> > System:
> >   Host: gx28b Kernel: 5.7.11-1-default i686 bits: 32
> >   Desktop: KDE Plasma 5.21.1 Distro: openSUSE Tumbleweed 20210307
>
> > No, it's not Debian. I never put Plasma on my Debians, which all use
TDE. This was
> > a freshly updated Tumbleweed, so the Plasma version is fresh. There's
no XFCE on
> > it. It won't be added either, as there's nothing about it I like better
than KDE3,
> > TDE or Plasma, and the disk has no room for more additions, worthwhile
or
> > otherwise. Thus, the difference between XFCE and Plasma or IceWM will
need a
> > different PC.
>
> > The point is, Plasma can be rather lean, using only 116260 more than
IceWM to get
> > a basic session started.
>
> The following isn't directly comparable to the above, as the Plasma
installation
> and user are anything but fresh. However, it is a minimal, and started up
in same
> manner, just on 64 bits instead of 32, and the same Plasma version on the
same OS
> release, with 270996 instead of 136728 used to start a session:
>
> # fresh boot to multi-user before startx into Plasma & Konsole
>totalusedfree  shared  buff/cache
 available
> Mem: 3934880   92840 36121649912  229876
 3601836
> Swap:4200428   0 4200428
> # after startx into Plasma & Konsole
>totalusedfree  shared  buff/cache
 available
> Mem: 3934880  363836 3040312   75688  530732
 3250656
> Swap:4200428   0 4200428
>   270996 used by Plasma & Konsole
> # inxi -CGIMSy
> System:
>   Host: gx745 Kernel: 5.10.16-1-default x86_64 bits: 64

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[Cmdte Alpha Tigre Z]

> I recommend to use "testing" (currently Bullseye) on an individual
Laptop/Desktop Computer, and leave "stable" for server or cooperate end
user installations. Usually "testing" is very stable concerning reliability
for the every day interactive work and during the frequent upgrades (which
you should frequently apply).
>
> "stable" is so stable, that it already when published is not being
perfectly up to date anymore with the newest software versions available.
But for sure the provided software releases are so long time tested that no
mayor bugs are expected to hit you under usual circumstances.
> Where you cannot risk the work load to maybe having to react on
complaining users, or your running system simply does not need much
modernization because it is doing its job and then better don't touch it
unless a security update would need to be applied, then "stable" is
excellent.
>
> If a user is willing to step by step face the changes of a system
following current software releases, then "testing" is offering this to
you. The all over experience of the users with "testing is, that it rarely
breaks. Actually I never experienced this. It simply runs. It is not long
time tested as "stable" because everything is always in the "testing"
period for the next "stable", but "testing" does not mean "unstable". The
comfort of having modern software releases available instead of feeling
parked for years on unchanged apps is often worth the risk to maybe run
into a bug found in a new release. In my experiences, these bugs then are
usually not mission critical and users can most often afford to wait that
the bug gets solved by a soon delivered next release of the software, which
you can expect to soon also arrive in the "testing" distribution of Debian.
>
> So, Debian "stable" is for mission critical apps and services, therefore
not offering short time only tested, newest software. Debian "testing"
brings the comfort of much more up-to-date software to the screen and is
commonly stable enough for the continuous, interactive desktop usage.
>
>
>
> > Apparently, only the newer versions of KDE Plasma have the performance
> > boost.
>
> I cannot confirm this. KDE Plasma is high performant and low on memory
usage for years already. This was different in the far past. Consider that
the internet does not forget and still shows you complains from the past
although they might not apply to the current situation anymore. Also,
enthusiast of other graphical desktop environments sometimes still publish
such obsolete information, maybe because they years ago became full
satisfied with their desktop of choice and since then did not notice the
changes around anymore and are now no more well informed?
> Having had the urgent need for a more modern but also low footprint
desktop to subtitute Window Maker, I years ago did not consider KDE as my
candidate, because of information from highly ranked links in the web
search engines. I ended up testing Xfce, Openbox and LXDE. And I tested
LXQt, which was still in experimental state that time - and found that the
window manager in use by LXQt could be exchanged for various available
candidates. Noticing that kwin performed excellent in LXQt I wondered why
KDE was reported to be sluggish and heavy on resources, if its component
kwin was performing so excellently in LXQt. I gave KDE Plasma a try and
found to have been blinded by obsolete reports still popping up high ranked
in the web search engines. KDE Plasma was that time already a very nice
choice for old machines, and nowadays it continuous to do so. KDE Plasma
resource requirements compete very well with other "small footprint"
desktop environments. In the end you might ask why I then decided for KDE
over LXQt with kwin. Well it is because I much like the administration of
keyboard shortcuts in KDE Plasma, and I much like Kate and Konsole, and
also Dolphin and Krunner are very competitive, and baloo is quite helpful
once the initial indexing is achieved. All this comes with KDE Plasma kind
of out of the box - and perfectly competitive where only small hardware
resources are available.
>
> Best wishes, Marco.
>

Very impressive that you can even compare KDE Plasma to LXQt.

I don't think there is a Debian DVD iso I can use to install Debian
Bullseye.
I think I'll have to install Buster and then switch to Bullseye.
Is there a better option?

Thank you and thanks everyone for all your help.

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[Cmdte Alpha Tigre Z]

> If you have the drive-space for it, install it, along with something
lighter like Cinnamon or LXQt.
>
> Then all it takes to switch between the alternatives is to log out, find
the settings icon on your login manager, select your alternative, and log
back in.
>
> If KDE proves to be too sluggish, log out/in, switching to a leaner
alternative.
>
> You can install and try dozens of alternatives.
> --
> Kent West<")))><
> Westing Peacefully - http://kentwest.blogspot.com

Thanks for the suggestion.  But, according to the others here
I think that everything should go fine.

I'm a little optimistic now.  Everything I was looking is an opinion
from someone already using KDE Plasma and some advice.

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[Cmdte Alpha Tigre Z]

> Debian bullseye (soon to be Debian 11) is already in the "freeze" stage.
>
> It should be quite reliable in daily usage though you are still going to
> see (small) updates to many packages.
>
> Official security support is not started yet, but security relevant
> updates should be prioritised whenever possible.
>
> In my opinion it should be fine for a desktop system, but I wouldn't run
> it on a server exposed to the internet.
>
> Kind regard,
> Andrei
> --
> http://wiki.debian.org/FAQsFromDebianUser

Thanks for the advice

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[Marco Möller]

On 10.03.21 13:51, Cmdte Alpha Tigre Z wrote:
(...)
My last doubt is if should use Debian 10 with KDE Plasma or Debian 
Bullseye instead.


I recommend to use "testing" (currently Bullseye) on an individual 
Laptop/Desktop Computer, and leave "stable" for server or cooperate end 
user installations. Usually "testing" is very stable concerning 
reliability for the every day interactive work and during the frequent 
upgrades (which you should frequently apply).


"stable" is so stable, that it already when published is not being 
perfectly up to date anymore with the newest software versions 
available. But for sure the provided software releases are so long time 
tested that no mayor bugs are expected to hit you under usual circumstances.
Where you cannot risk the work load to maybe having to react on 
complaining users, or your running system simply does not need much 
modernization because it is doing its job and then better don't touch it 
unless a security update would need to be applied, then "stable" is 
excellent.


If a user is willing to step by step face the changes of a system 
following current software releases, then "testing" is offering this to 
you. The all over experience of the users with "testing is, that it 
rarely breaks. Actually I never experienced this. It simply runs. It is 
not long time tested as "stable" because everything is always in the 
"testing" period for the next "stable", but "testing" does not mean 
"unstable". The comfort of having modern software releases available 
instead of feeling parked for years on unchanged apps is often worth the 
risk to maybe run into a bug found in a new release. In my experiences, 
these bugs then are usually not mission critical and users can most 
often afford to wait that the bug gets solved by a soon delivered next 
release of the software, which you can expect to soon also arrive in the 
"testing" distribution of Debian.


So, Debian "stable" is for mission critical apps and services, therefore 
not offering short time only tested, newest software. Debian "testing" 
brings the comfort of much more up-to-date software to the screen and is 
commonly stable enough for the continuous, interactive desktop usage.



> Apparently, only the newer versions of KDE Plasma have the performance
> boost.

I cannot confirm this. KDE Plasma is high performant and low on memory 
usage for years already. This was different in the far past. Consider 
that the internet does not forget and still shows you complains from the 
past although they might not apply to the current situation anymore. 
Also, enthusiast of other graphical desktop environments sometimes still 
publish such obsolete information, maybe because they years ago became 
full satisfied with their desktop of choice and since then did not 
notice the changes around anymore and are now no more well informed?
Having had the urgent need for a more modern but also low footprint 
desktop to subtitute Window Maker, I years ago did not consider KDE as 
my candidate, because of information from highly ranked links in the web 
search engines. I ended up testing Xfce, Openbox and LXDE. And I tested 
LXQt, which was still in experimental state that time - and found that 
the window manager in use by LXQt could be exchanged for various 
available candidates. Noticing that kwin performed excellent in LXQt I 
wondered why KDE was reported to be sluggish and heavy on resources, if 
its component kwin was performing so excellently in LXQt. I gave KDE 
Plasma a try and found to have been blinded by obsolete reports still 
popping up high ranked in the web search engines. KDE Plasma was that 
time already a very nice choice for old machines, and nowadays it 
continuous to do so. KDE Plasma resource requirements compete very well 
with other "small footprint" desktop environments. In the end you might 
ask why I then decided for KDE over LXQt with kwin. Well it is because I 
much like the administration of keyboard shortcuts in KDE Plasma, and I 
much like Kate and Konsole, and also Dolphin and Krunner are very 
competitive, and baloo is quite helpful once the initial indexing is 
achieved. All this comes with KDE Plasma kind of out of the box - and 
perfectly competitive where only small hardware resources are available.


Best wishes, Marco.

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[Kent West]

On Tue, Mar 9, 2021 at 9:34 PM Cmdte Alpha Tigre Z 
wrote:

> Hello.
>
> I would like to install Debian 10 with the KDE Plasma task
> on a PC with 4 GB of RAM and Intel Core 2 Duo E6550 @ 2.33 GHz,
> it doesn't have a GPU.
> Do you think it would run without problems
> or would it be slow and laggy?
>
> Thanks in advance for your answers.
>

If you have the drive-space for it, install it, along with something
lighter like Cinnamon or LXQt.

Then all it takes to switch between the alternatives is to log out, find
the settings icon on your login manager, select your alternative, and log
back in.

If KDE proves to be too sluggish, log out/in, switching to a leaner
alternative.

You can install and try dozens of alternatives.
-- 
Kent West<")))><
Westing Peacefully - http://kentwest.blogspot.com

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[Andrei POPESCU]

On Mi, 10 mar 21, 08:51:33, Cmdte Alpha Tigre Z wrote:
> 
> My last doubt is if should use Debian 10 with KDE Plasma or Debian Bullseye
> instead.
> Apparently, only the newer versions of KDE Plasma have the performance
> boost.

Debian bullseye (soon to be Debian 11) is already in the "freeze" stage. 

It should be quite reliable in daily usage though you are still going to 
see (small) updates to many packages.

Official security support is not started yet, but security relevant 
updates should be prioritised whenever possible.

In my opinion it should be fine for a desktop system, but I wouldn't run 
it on a server exposed to the internet.

Kind regard,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[Cmdte Alpha Tigre Z]

El 10/03/2021 07:53, "Marco Möller" 
escribió:
>
>
> On 10.03.21 04:34, Cmdte Alpha Tigre Z wrote:
>>
>> Hello.
>>
>> I would like to install Debian 10 with the KDE Plasma task
>> on a PC with 4 GB of RAM and Intel Core 2 Duo E6550 @ 2.33 GHz,
>> it doesn't have a GPU.
>> Do you think it would run without problems
>> or would it be slow and laggy?
>>
>> Thanks in advance for your answers.
>>
> I am happily using KDE Plasma on such a system as my daily system with
the following restrictions:
> (1) The L2 cache of your CPU should have 3 MiB or more; with only 2 MiB
it is not always responsive as wished, and with only 1 MiB it is due to low
responsiveness in my experience not usable anymore; the number of CPU
cores, threads and frequency in my experience are not the key factors for a
responsive = smoothly usable system;
> (2) You might want to limit or deactivate the automatic indexing provided
by "baloo", configurable also in the System Settings GUI under "Search" in
subcategories "File Search" and "KRunner"; right after installation it
wants to index all your system, and the system might in this state not be
responsive for some 2 days; I therefore deactivate this as soon as
possible, get the rest of my system set up and usable, and only later, when
I can leave the system run for a weekend without the need to interactively
work with it, I reactivate baloo features again, but only the ones for
which I indeed know that I want to use them; once the initially very system
consuming indexing is done, this baloo provided search "accelerator" does
not impact responsiveness anymore; it continues in the background to
smoothly update the indexing of newly added content without interfering
with the actions called in the foreground by the user;
> (3) I am sorry having to suggest even as an enthusiastic KDE user, that
you might want to avoid installing the KDE PIM suite related apps like
KMail; although I loved the design of its GUI and work flow a lot, it was
not only slowing down the responsiveness of the desktop often, but also
crashed too often; this experience is from 5 and from 2.5 years ago; after
this bad experiences and Thunderbird meanwhile being very well maintained
again, I am not going to give KMail another try and will very satisfied
stay with Thunderbird for email, calendar and address book;
>
> I finally 2.5 years ago came from long time back in the past GNOME usage,
then Xfce, then Openbox, then LXDE, then LXQt, then LXQt with kwin usage to
KDE Plasma and confirm that KDE Plasma is very competitive on memory and
speed. I do not see any reason for not using it on old machines, see my
system specifications attached below. You will see that I am on KDE Plasma
as currently offered in "Debian/testing - bullseye" and do not know about
the very newest version 5.21.
>
> Operating System: Debian GNU/Linux
> KDE Plasma Version: 5.20.5
> KDE Frameworks Version: 5.78.0
> Qt Version: 5.15.2
> Kernel Version: 5.10.0-4-amd64
> OS Type: 64-bit
> Processors: 2 × Intel® Core™2 Duo CPU P7450 @ 2.13GHz
> Memory: 2,9 GiB of RAM
> Graphics Processor: Mesa DRI Mobile Intel® GM45 Express Chipset
>
> The CPU and memory consumption of pure KDE Plasma with only the "Konsole"
terminal app open for generating the presented data are these:
>
> $ sudo inxi -Cm
> Memory:RAM: total: 2.88 GiB used: 1.2 GiB (41.8%)
> Array-1: capacity: 4 GiB slots: 2 EC: None
> Device-1: M1 size: 2 GiB speed: 667 MT/s
> Device-2: M2 size: 2 GiB speed: 667 MT/s
> CPU:   Info: Dual Core model: Intel Core2 Duo P7450 bits: 64 type:
MCP L2 cache: 3 MiB
> Speed: 798 MHz min/max: 800/2133 MHz Core speeds (MHz): 1: 798 2: 798
>
> $ free -h
>totalusedfree  shared  buff/cache
available
> Mem:   2.9Gi   779Mi   1.2Gi   282Mi   959Mi
 1.7Gi
> Swap:  7.6Gi71Mi   7.6Gi
>
> You will see that pure KDE Plasma is easily provided at lowest processor
speed and with a smaller than 800 MB memory footprint.
>
>
> If running Thunderbird for writing this answer to you, having a messenger
app running, having the System Monitor and the terminal app Konsole started
in order to check for you my current memory usage, and having Firefox open
with 6 Tabs while all Firefox cache for better responsiveness is placed in
the RAM and not on the HDD (actually I am running all my system even
without a HDD from a USB2.0 pendrive only), you will see that the CPU is
busy - but my system is still nicely responsive and doing for me flawlessly
what I ask it to do.
> You might have noticed that on my hardware I am only getting access to 3
GiB RAM, although 4 GiB are installed, and I never found out how I could
overcome this limitation.
> When &q

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[Cmdte Alpha Tigre Z]

> Commandante Alpha-
> Full disclosure, I have always preferred KDE over gnome and alternatives.
It's just more complete and tight. But there are some older systems I can't
really use it on. I don't NEED a massive window manager and apps, I was a
fan of twm for years. I dont mind xfce either, it's light and solid. But
can't really be compared to KDE. Over and out.
> SubCommandante Geovanis 😊

Received, SubCommandante Geovanis.
Looks like it might deserve a try.
Commandante Alpha, out.
:)

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[Nicholas Geovanis]

On Wed, Mar 10, 2021, 5:23 AM Cmdte Alpha Tigre Z 
wrote:

> > I would not do that. I run xfce under Debian 10.4 in 8GB, it's very
> light weight for a window manager. MUCH lighter than KDE. But still a
> little slow sometimes, with more than a few apps open SubCommandante
> Geovanis
> > 😂
>
> Oh, it looks it would be very slowly then.
> It is weird is doesn't looks like I have been reading:
>
> https://www.forbes.com/sites/jasonevangelho/2019/10/23/bold-prediction-kde-will-steal-the-lightweight-linux-desktop-crown-in-2020/?sh=763cb23826d2
>
> I can't say anything about, because I never used any of them.
>
Commandante Alpha-
Full disclosure, I have always preferred KDE over gnome and alternatives.
It's just more complete and tight. But there are some older systems I can't
really use it on. I don't NEED a massive window manager and apps, I was a
fan of twm for years. I dont mind xfce either, it's light and solid. But
can't really be compared to KDE. Over and out.
SubCommandante Geovanis 😊

>

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[Marco Möller]

On 10.03.21 04:34, Cmdte Alpha Tigre Z wrote:

Hello.

I would like to install Debian 10 with the KDE Plasma task
on a PC with 4 GB of RAM and Intel Core 2 Duo E6550 @ 2.33 GHz,
it doesn't have a GPU.
Do you think it would run without problems
or would it be slow and laggy?

Thanks in advance for your answers.

I am happily using KDE Plasma on such a system as my daily system with 
the following restrictions:
(1) The L2 cache of your CPU should have 3 MiB or more; with only 2 MiB 
it is not always responsive as wished, and with only 1 MiB it is due to 
low responsiveness in my experience not usable anymore; the number of 
CPU cores, threads and frequency in my experience are not the key 
factors for a responsive = smoothly usable system;
(2) You might want to limit or deactivate the automatic indexing 
provided by "baloo", configurable also in the System Settings GUI under 
"Search" in subcategories "File Search" and "KRunner"; right after 
installation it wants to index all your system, and the system might in 
this state not be responsive for some 2 days; I therefore deactivate 
this as soon as possible, get the rest of my system set up and usable, 
and only later, when I can leave the system run for a weekend without 
the need to interactively work with it, I reactivate baloo features 
again, but only the ones for which I indeed know that I want to use 
them; once the initially very system consuming indexing is done, this 
baloo provided search "accelerator" does not impact responsiveness 
anymore; it continues in the background to smoothly update the indexing 
of newly added content without interfering with the actions called in 
the foreground by the user;
(3) I am sorry having to suggest even as an enthusiastic KDE user, that 
you might want to avoid installing the KDE PIM suite related apps like 
KMail; although I loved the design of its GUI and work flow a lot, it 
was not only slowing down the responsiveness of the desktop often, but 
also crashed too often; this experience is from 5 and from 2.5 years 
ago; after this bad experiences and Thunderbird meanwhile being very 
well maintained again, I am not going to give KMail another try and will 
very satisfied stay with Thunderbird for email, calendar and address book;


I finally 2.5 years ago came from long time back in the past GNOME 
usage, then Xfce, then Openbox, then LXDE, then LXQt, then LXQt with 
kwin usage to KDE Plasma and confirm that KDE Plasma is very competitive 
on memory and speed. I do not see any reason for not using it on old 
machines, see my system specifications attached below. You will see that 
I am on KDE Plasma as currently offered in "Debian/testing - bullseye" 
and do not know about the very newest version 5.21.


Operating System: Debian GNU/Linux
KDE Plasma Version: 5.20.5
KDE Frameworks Version: 5.78.0
Qt Version: 5.15.2
Kernel Version: 5.10.0-4-amd64
OS Type: 64-bit
Processors: 2 × Intel® Core™2 Duo CPU P7450 @ 2.13GHz
Memory: 2,9 GiB of RAM
Graphics Processor: Mesa DRI Mobile Intel® GM45 Express Chipset

The CPU and memory consumption of pure KDE Plasma with only the 
"Konsole" terminal app open for generating the presented data are these:


$ sudo inxi -Cm
Memory:RAM: total: 2.88 GiB used: 1.2 GiB (41.8%)
Array-1: capacity: 4 GiB slots: 2 EC: None
Device-1: M1 size: 2 GiB speed: 667 MT/s
Device-2: M2 size: 2 GiB speed: 667 MT/s
CPU:   Info: Dual Core model: Intel Core2 Duo P7450 bits: 64 type: 
MCP L2 cache: 3 MiB

Speed: 798 MHz min/max: 800/2133 MHz Core speeds (MHz): 1: 798 2: 798

$ free -h
   totalusedfree  shared  buff/cache 
available
Mem:   2.9Gi   779Mi   1.2Gi   282Mi   959Mi 
  1.7Gi

Swap:  7.6Gi71Mi   7.6Gi

You will see that pure KDE Plasma is easily provided at lowest processor 
speed and with a smaller than 800 MB memory footprint.



If running Thunderbird for writing this answer to you, having a 
messenger app running, having the System Monitor and the terminal app 
Konsole started in order to check for you my current memory usage, and 
having Firefox open with 6 Tabs while all Firefox cache for better 
responsiveness is placed in the RAM and not on the HDD (actually I am 
running all my system even without a HDD from a USB2.0 pendrive only), 
you will see that the CPU is busy - but my system is still nicely 
responsive and doing for me flawlessly what I ask it to do.
You might have noticed that on my hardware I am only getting access to 3 
GiB RAM, although 4 GiB are installed, and I never found out how I could 
overcome this limitation.
When "inxi" (see below) reports that almost all this 3 GB of RAM would 
be in use, then this is because Debian is nicely using all RAM not 
claimed by my running apps for caching, in my configuration mainly for 
caching file system information. So, all memory is fully in use, this is 
how

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[Gene Heskett]

On Wednesday 10 March 2021 06:26:22 Cmdte Alpha Tigre Z wrote:

> > Yes, I think it will not work - better try lighter desktops or the
> > older
>
> KDE
>
> > that is called now Trinity Desktop
>
> How is that TDE?  Is it like KDE but much lighter?
> What are the main differences?
>
> Sorry, I'm new to GNU/Linux OSes.

TDE is a fork of KDE at the 3.5 level, with thousands of 3.5's bugs since 
fixed. Solid, like a piece of granite. And I've been running it for 
years on a milling machine with 2GB of dram and an old pentium cpu. But 
I don't do email on that box. And it was replaced with an old dell with 
a 4 core i5 and 4GB of dram about 3 weeks back. Future-proofing my cnc 
machinery.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[Cmdte Alpha Tigre Z]

> Yeah it will work, although it'll work a lot better if you can get an
extra 4Gb off Ebay, I paid about  £25.

By it will work you mean: your computer will boot; or: it will be usable?
He he, thanks for your help.

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[Cmdte Alpha Tigre Z]

> Try Enlightenment.
> It's very configurable once get familiar with all the options.
> Cheers!

I saw it was there, but it looks a little difficult to get it
working according to what I read about it.

Also, I don't know if loading Gtk+, Qt and EFL at the same
time at RAM would be a good idea.  But, well... maybe I'm wrong, I don't
know really, just guessing.

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[James Allsopp]

Also, you could spend a bit on money on an SSD, I did.

On Wed, 10 Mar 2021 at 11:31, James Allsopp 
wrote:

> Yeah it will work, although it'll work a lot better if you can get an
> extra 4Gb off Ebay, I paid about  £25.
>
> For reference I was running it on a 3Ghz 4GbRam Core2Duo.
>
> On Wed, 10 Mar 2021 at 11:23, Cmdte Alpha Tigre Z 
> wrote:
>
>> > I would not do that. I run xfce under Debian 10.4 in 8GB, it's very
>> light weight for a window manager. MUCH lighter than KDE. But still a
>> little slow sometimes, with more than a few apps open SubCommandante
>> Geovanis
>> > 😂
>>
>> Oh, it looks it would be very slowly then.
>> It is weird is doesn't looks like I have been reading:
>>
>> https://www.forbes.com/sites/jasonevangelho/2019/10/23/bold-prediction-kde-will-steal-the-lightweight-linux-desktop-crown-in-2020/?sh=763cb23826d2
>>
>> I can't say anything about, because I never used any of them.
>>
>

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[James Allsopp]

Yeah it will work, although it'll work a lot better if you can get an extra
4Gb off Ebay, I paid about  £25.

For reference I was running it on a 3Ghz 4GbRam Core2Duo.

On Wed, 10 Mar 2021 at 11:23, Cmdte Alpha Tigre Z 
wrote:

> > I would not do that. I run xfce under Debian 10.4 in 8GB, it's very
> light weight for a window manager. MUCH lighter than KDE. But still a
> little slow sometimes, with more than a few apps open SubCommandante
> Geovanis
> > 😂
>
> Oh, it looks it would be very slowly then.
> It is weird is doesn't looks like I have been reading:
>
> https://www.forbes.com/sites/jasonevangelho/2019/10/23/bold-prediction-kde-will-steal-the-lightweight-linux-desktop-crown-in-2020/?sh=763cb23826d2
>
> I can't say anything about, because I never used any of them.
>

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[Cmdte Alpha Tigre Z]

> Yes, I think it will not work - better try lighter desktops or the older
KDE
> that is called now Trinity Desktop

How is that TDE?  Is it like KDE but much lighter?
What are the main differences?

Sorry, I'm new to GNU/Linux OSes.

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[Cmdte Alpha Tigre Z]

> I would not do that. I run xfce under Debian 10.4 in 8GB, it's very light
weight for a window manager. MUCH lighter than KDE. But still a little slow
sometimes, with more than a few apps open SubCommandante Geovanis
> 😂

Oh, it looks it would be very slowly then.
It is weird is doesn't looks like I have been reading:
https://www.forbes.com/sites/jasonevangelho/2019/10/23/bold-prediction-kde-will-steal-the-lightweight-linux-desktop-crown-in-2020/?sh=763cb23826d2

I can't say anything about, because I never used any of them.

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[Weaver]

On 10-03-2021 17:05, deloptes wrote:
> Cmdte Alpha Tigre Z wrote:
> 
>> I would like to install Debian 10 with the KDE Plasma task
>> on a PC with 4 GB of RAM and Intel Core 2 Duo E6550 @ 2.33 GHz,
>> it doesn't have a GPU.
>> Do you think it would run without problems
>> or would it be slow and laggy?
> 
> Yes, I think it will not work - better try lighter desktops or the older KDE
> that is called now Trinity Desktop

Try Enlightenment.
It's very configurable once get familiar with all the options.
Cheers!

Harry

-- 
`The World is not dangerous because of those who do harm but
 because of those who look on without doing anything'.
 -- Albert Einstein

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[deloptes]

Cmdte Alpha Tigre Z wrote:

> I would like to install Debian 10 with the KDE Plasma task
> on a PC with 4 GB of RAM and Intel Core 2 Duo E6550 @ 2.33 GHz,
> it doesn't have a GPU.
> Do you think it would run without problems
> or would it be slow and laggy?

Yes, I think it will not work - better try lighter desktops or the older KDE
that is called now Trinity Desktop

Re: Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[Nicholas Geovanis]

On Tue, Mar 9, 2021, 9:34 PM Cmdte Alpha Tigre Z 
wrote:

> Hello.
>
> I would like to install Debian 10 with the KDE Plasma task
> on a PC with 4 GB of RAM and Intel Core 2 Duo E6550 @ 2.33 GHz,
> it doesn't have a GPU.
> Do you think it would run without problems
> or would it be slow and laggy?
>
> I would not do that. I run xfce under Debian 10.4 in 8GB, it's very light
weight for a window manager. MUCH lighter than KDE. But still a little slow
sometimes, with more than a few apps open SubCommandante Geovanis
😂

> Thanks in advance for your answers.
>

Could KDE work adequately on a PC with 4 GB of RAM and an Intel Core 2 Duo processor @ 2.33 GHz?

[Cmdte Alpha Tigre Z]

Hello.

I would like to install Debian 10 with the KDE Plasma task
on a PC with 4 GB of RAM and Intel Core 2 Duo E6550 @ 2.33 GHz,
it doesn't have a GPU.
Do you think it would run without problems
or would it be slow and laggy?

Thanks in advance for your answers.

Re: Free-services lead to increased RAM and CPU requirements

[John Hasler]

Andrei writes:
> It seems to me rhkramer is referring to this:
> https://www.nytimes.com/2020/10/06/technology/congress-big-tech-monopoly-power.html

So institute regulations forcing Amazon to shut down its "marketplace"
and sell only its own products (or rather ones they purchase: they make
nothing), Facebook to merge its two social media utilities into a single
subsiduary (which would have no effect on what the users see but would
make coordination easier), etc.

Anything to avoid changing the tax laws (i.e., capital gains exemptions
and double taxation) the are the incentive for companies to choose
growth over dividends.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: Free-services lead to increased RAM and CPU requirements

[Andrei POPESCU]

On Mi, 28 oct 20, 08:26:15, John Hasler wrote:
> rhkramer writes:
> > Investigations started in the US congress (and, iirc, in the EC
> > counterparts) may lead to de-monopolizing some of those services.
> 
> If you are referring to the efforts to gut the DMCA "safe harbor"
> provisions that will have the opposite effect.  Same for the efforts to
> impose Chinese-style "voluntary" censorship.  These sorts of things
> impose large costs which do not scale with the size of the organization.
> This will lead to an oligopoly of a few very large heavily regulated
> organizations, leading to calls for even more regulation.

It seems to me rhkramer is referring to this:
https://www.nytimes.com/2020/10/06/technology/congress-big-tech-monopoly-power.html

(just one of the articles I quickly found via a web search that appears 
to be readable without a subscription)

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Free-services lead to increased RAM and CPU requirements

[John Hasler]

rhkramer writes:
> Investigations started in the US congress (and, iirc, in the EC
> counterparts) may lead to de-monopolizing some of those services.

If you are referring to the efforts to gut the DMCA "safe harbor"
provisions that will have the opposite effect.  Same for the efforts to
impose Chinese-style "voluntary" censorship.  These sorts of things
impose large costs which do not scale with the size of the organization.
This will lead to an oligopoly of a few very large heavily regulated
organizations, leading to calls for even more regulation.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: Free-services lead to increased RAM and CPU requirements (was: Re: Replacement Email Client)

[Andrei POPESCU]

On Mi, 28 oct 20, 07:12:19, rhkra...@gmail.com wrote:
> On Wednesday, October 28, 2020 04:35:46 AM to...@tuxteam.de wrote:
> > How did we end here? How did we end up paying for the ad
> > industry's infrastrutcture, paying with our privacy, but
> > also with our real money, having to buy RAM and CPU power
> > just for their sake?
> 
> Assuming that is not a rhetorical question, or answering for posterity, it 
> was 
> primarily by accepting the word "free" in their promises of free services at 
> face value.

Client-side scripting does enable services like ProtonMail to exist as 
well.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Free-services lead to increased RAM and CPU requirements (was: Re: Replacement Email Client)

[rhkramer]

On Wednesday, October 28, 2020 04:35:46 AM to...@tuxteam.de wrote:
> How did we end here? How did we end up paying for the ad
> industry's infrastrutcture, paying with our privacy, but
> also with our real money, having to buy RAM and CPU power
> just for their sake?

Assuming that is not a rhetorical question, or answering for posterity, it was 
primarily by accepting the word "free" in their promises of free services at 
face value.

> How do we get out of here?

Don't know.  It was / is a tradeoff.  For some of us, and with appropriate 
protective measures, maybe it has been and still is a reasonable tradeoff.

Investigations started in the US congress (and, iirc, in the EC counterparts) 
may lead to de-monopolizing some of those services.  I'm not sure that will 
help all that much, or to say it another way, when that happens, those 
companies will find more ways to try to achieve large profits (which, 
generally, 
are at our expense).

I wouldn't mind seeing some discussion of appropriate ideas.

Re: Could RAM possibly be just 3-4 times faster than bare hdd writes and reads? or, is the Linux kernel doing its 'magic' in the bg? or, ...

[Michael Stone]

On Thu, Jun 18, 2020 at 05:28:11PM +0300, Reco wrote:

Hi.

On Thu, Jun 18, 2020 at 08:57:48AM -0400, Michael Stone wrote:

On Thu, Jun 18, 2020 at 08:50:49AM +0300, Reco wrote:
> On Wed, Jun 17, 2020 at 05:54:51PM -0400, Michael Stone wrote:
> > On Wed, Jun 17, 2020 at 11:45:53PM +0300, Reco wrote:
> > > Long story short, if you need a primitive I/O benchmark, you're better
> > > with both dsync and nocache.
> >
> > Not unless that's your actual workload, IMO. Almost nothing does sync i/o;
>
> Almost everything does (see my previous e-mails). No everything does it
> with O_DSYNC, that's true.

You're not using the words like most people use them, which does certainly 
confuse the conversation.


Earlier this thread someone posted a link to Wikipedia article on the
matter. Whatever terminology I'm using is consistent with it.
Qualifies for "common terminology" IMO.


It would really be better to just drop any kind of metaphysical argument 
about what to call things and just focus on command lines and other 
concrete examples. Again, you seem fixated on certain APIs and then 
making leaps in other contexts where the distinctions you're trying to 
make don't apply.



writing one block at a time is *really* *really* bad for performance.


True. But also it's good for the integrity of written data, which is why
(presumably) sqlite upstream did it.



strace -e open,openat,fsync,fdatasync sqlite3 test.sqlite3

[snip]
SQLite version 3.32.2 2020-06-04 12:58:43
Enter ".help" for usage hints.
[snip]
sqlite> create table test (test varchar);  
openat(AT_FDCWD, "test.sqlite3", O_RDONLY) = -1 ENOENT (No such file or directory)

openat(AT_FDCWD, "/tmp/test.sqlite3", O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 
0644) = 5
openat(AT_FDCWD, "/tmp/test.sqlite3-journal", 
O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0644) = 6
openat(AT_FDCWD, "/dev/urandom", O_RDONLY|O_CLOEXEC) = 7
fdatasync(6)= 0
openat(AT_FDCWD, "/tmp", O_RDONLY|O_CLOEXEC) = 7
fdatasync(7)= 0
fdatasync(6)= 0
fdatasync(5)= 0
sqlite> insert into test VALUES ('foo');
openat(AT_FDCWD, "/tmp/test.sqlite3-journal", 
O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0644) = 6
fdatasync(6)= 0
openat(AT_FDCWD, "/tmp", O_RDONLY|O_CLOEXEC) = 7
fdatasync(7)= 0
fdatasync(6)= 0
fdatasync(5)= 0
sqlite> update test set test = 'bar';
openat(AT_FDCWD, "/tmp/test.sqlite3-journal", 
O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0644) = 6
fdatasync(6)= 0
openat(AT_FDCWD, "/tmp", O_RDONLY|O_CLOEXEC) = 7
fdatasync(7)= 0
fdatasync(6)= 0
fdatasync(5)= 0

No O_DSYNCs to be seen, but quite a few fdatasync's! You don't seem to 
be checking that what you're saying matches actual practice & behavior.



Most applications for which I/O performance is important allow writes to 
buffer, then
flush the buffers as needed for data integrity.


No objections here. Most applications write their files as a whole, it
makes total sense to do it this way. But there are exceptions to this
rule, and if it modifies its files piecewise, it probably uses O_DSYNC
to be sure.


See above.


> > simply using conv=fdatasync to make sure that the cache is flushed before 
exiting
> > is going to be more representative.
>
> If you're answering the question "how fast is my programs are going to
> write there" - sure. If you're answering the question "how fast my
> drive(s) actually is(are)" - nope, you need O_DSYNC.

While OF COURSE the question people want answered is "how fast is my programs are 
going to write there"


But the most important hidden question here - which programs?
That ones that write their files by one big chunk (which is common) or
the ones that do it one piece at a time (any RDBMS, for instance)?


See above. RDBMS usually try really hard to coalesce write operations 
rather than writing little tiny pieces, even at the cost of writing the 
data twice. (Once in a sequential journal, and again as part of combined

random writes.)

Real programs that write large amounts of data have to handle the 
possibility of partial writes *even if* they are using O_DSYNC. In 
non-trivial cases if you're doing the work to handle the problems that 
occur with a partial write, you can just as easily write larger amounts 
of data unsynchronized to get better performance, then establish a 
synchronization point with f(data)sync. There are cases where O_DSYNC 
might be the best option, mostly around appending in relatively small 
chunks. Otherwise, as above, you're probably using some kind of journal 
and there's no reason to slow down every operation when you only need 
things to hit the disk in a certain relative order to get the same 
level of integrity.


This is also all stuff that's evolved over time

Re: Could RAM possibly be just 3-4 times faster than bare hdd writes and reads? or, is the Linux kernel doing its 'magic' in the bg? or, ...

[Reco]

Hi.

On Thu, Jun 18, 2020 at 08:57:48AM -0400, Michael Stone wrote:
> On Thu, Jun 18, 2020 at 08:50:49AM +0300, Reco wrote:
> > On Wed, Jun 17, 2020 at 05:54:51PM -0400, Michael Stone wrote:
> > > On Wed, Jun 17, 2020 at 11:45:53PM +0300, Reco wrote:
> > > > Long story short, if you need a primitive I/O benchmark, you're better
> > > > with both dsync and nocache.
> > > 
> > > Not unless that's your actual workload, IMO. Almost nothing does sync i/o;
> > 
> > Almost everything does (see my previous e-mails). No everything does it
> > with O_DSYNC, that's true.
> 
> You're not using the words like most people use them, which does certainly 
> confuse the conversation.

Earlier this thread someone posted a link to Wikipedia article on the
matter. Whatever terminology I'm using is consistent with it.
Qualifies for "common terminology" IMO.


> > Although if it uses sqlite - chances are it does it with O_DSYNC.
> 
> That may be true in some modes but not in my quick testing and wouldn't be 
> what I'd expect.

Every time I have to use yum(1) or dnf(1) I have to suffer because of it.
Luckily Debian uses apt(1) which miles ahead of them both in this
regard (dpkg(1) fdatasync on each file is a different story).


> writing one block at a time is *really* *really* bad for performance.

True. But also it's good for the integrity of written data, which is why
(presumably) sqlite upstream did it.


> Most applications for which I/O performance is important allow writes to 
> buffer, then
> flush the buffers as needed for data integrity.

No objections here. Most applications write their files as a whole, it
makes total sense to do it this way. But there are exceptions to this
rule, and if it modifies its files piecewise, it probably uses O_DSYNC
to be sure.


> Also note the subtlety of "synchronized" I/O vs "synchronous" I/O
> which is another thing that's really important in some contexts, but
> will just make what should be a simple answer more confusing if you
> follow the rabbit hole.

Duly noted.


> > > simply using conv=fdatasync to make sure that the cache is flushed before 
> > > exiting
> > > is going to be more representative.
> > 
> > If you're answering the question "how fast is my programs are going to
> > write there" - sure. If you're answering the question "how fast my
> > drive(s) actually is(are)" - nope, you need O_DSYNC.
> 
> While OF COURSE the question people want answered is "how fast is my programs 
> are going to write there"

But the most important hidden question here - which programs?
That ones that write their files by one big chunk (which is common) or
the ones that do it one piece at a time (any RDBMS, for instance)?


> rather than some other number like "how fast is some mode of writing that I 
> won't use",

Or rather - I won't usually use.
Ever wondered why Firefox gets sluggish if OS is I/O bound? Periodic
updates of sqlite databases with O_DSYNC, that's why.


I propose to leave it here as it is.

Reco

Re: Could RAM possibly be just 3-4 times faster than bare hdd writes and reads? or, is the Linux kernel doing its 'magic' in the bg? or, ...

[Michael Stone]

On Thu, Jun 18, 2020 at 08:50:49AM +0300, Reco wrote:

Hi.

On Wed, Jun 17, 2020 at 05:54:51PM -0400, Michael Stone wrote:

On Wed, Jun 17, 2020 at 11:45:53PM +0300, Reco wrote:
> Long story short, if you need a primitive I/O benchmark, you're better
> with both dsync and nocache.

Not unless that's your actual workload, IMO. Almost nothing does sync i/o;


Almost everything does (see my previous e-mails). No everything does it
with O_DSYNC, that's true.


You're not using the words like most people use them, which does 
certainly confuse the conversation. At a certain point it doesn't matter 
whether your interpretation is right or wrong--if you're arguing against 
the common usage that people will find the in man page and program 
arguments you're just making it harder to communicate. It doesn't help 
that you've latched on to one particular API, without clearly 
considering/communicating the entire stack and how different pieces of 
the stack may have overlapping terminology depending on their 
perspective. 


Although if it uses sqlite - chances are it
does it with O_DSYNC.


That may be true in some modes but not in my quick testing and wouldn't 
be what I'd expect. As open(2) says: 


  O_DSYNC
 Write operations on the file will complete accord-
 ing to the requirements of synchronized  I/O  data
 integrity completion.

 By  the  time  write(2)  (and similar) return, the
 output data has been transferred to the underlying
 hardware,  along with any file metadata that would
 be required to retrieve that data (i.e., as though
 each  write(2)  was  followed  by a call to fdata-
 sync(2)).  See NOTES below.

writing one block at a time is *really* *really* bad for performance. 
Most applications for which I/O performance is important allow writes to 
buffer, then flush the buffers as needed for data integrity. 

Also note the subtlety of "synchronized" I/O vs "synchronous" I/O which 
is another thing that's really important in some contexts, but will just 
make what should be a simple answer more confusing if you follow the 
rabbit hole.



simply using conv=fdatasync to make sure that the cache is flushed before 
exiting
is going to be more representative.


If you're answering the question "how fast is my programs are going to
write there" - sure. If you're answering the question "how fast my
drive(s) actually is(are)" - nope, you need O_DSYNC.


While OF COURSE the question people want answered is "how fast is my 
programs are going to write there" rather than some other number like 
"how fast is some mode of writing that I won't use", using dd's sync 
flag isn't even a better answer to the question "how fast my drive(s) 
actually is(are)" because it's probably going to be far slower than it 
needs to be unless you're using an unrealistically large block size. 
With the fdatasync option you'll find out how much time it takes the 
data to be committed to the drive, which certainly isn't *faster* than 
that the drive "actually" is...so you'll need to be a lot more clear on 
what's wrong with that number.


On old spinning disks this all didn't matter as much as the slow drive 
performance dominated the equation and a smaller (but still overly 
large) block size like 1M could paper over things. But on faster media 
the differences are more obvious:



dd if=/dev/zero of=testfil bs=1M oflag=dsync,nocache count=1000

1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 4.71833 s, 222 MB/s

dd if=/dev/zero of=testfil bs=128M oflag=dsync,nocache count=8

8+0 records in
8+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.45332 s, 739 MB/s

dd if=/dev/zero of=testfil bs=1M conv=fdatasync count=1000

1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 1.13529 s, 924 MB/s

dd if=/dev/zero of=testfil bs=64k conv=fdatasync count=16000

16000+0 records in
16000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 0.914076 s, 1.1 GB/s

See how the dsync,nocache version doesn't perform reasonably well 
without the ridiculously oversize 128M blocks, and even then is still 
relatively slow. Now see how the fdatasync version actually comes close 
to the correct speed for this SSD. Also very important to note that the 
block size doesn't really matter, and this 64k run is actually faster. 
Mostly they're statistically the same, with multiple runs averaging 
about the same and would get closer with a longer test--the key here is 
that the user doesn't have to worry about block sizes. (Also I aligned 
them in an orderly way for discussion, they don't actually just get 
faster over time.) Applications trying to squeeze every last bit of 
performance out of their storage need to very carefully tune their 
access patterns for the characteristics of a particular device (and how 
they're using that device). I've done that, it isn't fun, an

Re: Could RAM possibly be just 3-4 times faster than bare hdd writes and reads? or, is the Linux kernel doing its 'magic' in the bg? or, ...

[Reco]

Hi.

On Wed, Jun 17, 2020 at 05:54:51PM -0400, Michael Stone wrote:
> On Wed, Jun 17, 2020 at 11:45:53PM +0300, Reco wrote:
> > Long story short, if you need a primitive I/O benchmark, you're better
> > with both dsync and nocache.
> 
> Not unless that's your actual workload, IMO. Almost nothing does sync i/o;

Almost everything does (see my previous e-mails). No everything does it
with O_DSYNC, that's true.  Although if it uses sqlite - chances are it
does it with O_DSYNC.


> simply using conv=fdatasync to make sure that the cache is flushed before 
> exiting
> is going to be more representative.

If you're answering the question "how fast is my programs are going to
write there" - sure. If you're answering the question "how fast my
drive(s) actually is(are)" - nope, you need O_DSYNC.

Reco

Re: Could RAM possibly be just 3-4 times faster than bare hdd writes and reads? or, is the Linux kernel doing its 'magic' in the bg? or, ...

[Andy Smith]

Hello,

On Wed, Jun 17, 2020 at 12:17:58PM +0200, Albretch Mueller wrote:
>  also, if in order to use RAID 10 you need 4 drives

Linux mdadm can do RAID-10 with 2 or more devices (also doesn't have
to be an even number).

> (but the dollar per Gb is approaching $0.02) and you get 1.5
> faster performance, what is the economy of "bying more RAM" if it
> is so much more expensive?

RAM and storage devices are completely different things, are used
for different things, and your question is unanswerable without a
better description of your workload and probably some benchmarking.

Also, even main system RAM is vastly faster than 3x HDD.

https://gist.github.com/jboner/2841832

like, 80 times faster.

>  Any comparison on HDD, SSD and RAM including pros and cons which is
> worth reading?

It's not possible to provide you with anything but the most basic
comparison unless you describe exactly what you are trying to do.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Could RAM possibly be just 3-4 times faster than bare hdd writes and reads? or, is the Linux kernel doing its 'magic' in the bg? or, ...

[Michael Stone]

On Wed, Jun 17, 2020 at 11:45:53PM +0300, Reco wrote:

Long story short, if you need a primitive I/O benchmark, you're better
with both dsync and nocache.


Not unless that's your actual workload, IMO. Almost nothing does sync 
i/o; simply using conv=fdatasync to make sure that the cache is flushed 
before exiting is going to be more representative.

Re: Could RAM possibly be just 3-4 times faster than bare hdd writes and reads? or, is the Linux kernel doing its 'magic' in the bg? or, ...

[Reco]

On Wed, Jun 17, 2020 at 11:02:14PM +0200, to...@tuxteam.de wrote:
> On Wed, Jun 17, 2020 at 11:45:53PM +0300, Reco wrote:
> 
> [...]
> 
> > Long story short, if you need a primitive I/O benchmark, you're better
> > with both dsync and nocache.
> 
> Thanks for actually looking over dd's shoulder :-)

You're welcome. strace(1), dear list readers, it's strace(1).
Have it, love it, use it.

Reco

Re: Could RAM possibly be just 3-4 times faster than bare hdd writes and reads? or, is the Linux kernel doing its 'magic' in the bg? or, ...

[Reco]

On Wed, Jun 17, 2020 at 01:23:41PM -0700, David Christensen wrote:
> On 2020-06-17 12:26, Reco wrote:
> 
> > On Wed, Jun 17, 2020 at 12:10:51PM -0700, David Christensen wrote:
> > > 2.  AIUI dd(1) uses asynchronous (buffered) I/O unless told otherwise.
> > 
> > You seem to confuse asynchronous and cached I/O too.
> > 
> > > From Linux kernel POV, *asynchronous* I/O is a pair of
> > io_submit/io_getevents syscalls, and dd does not do these regardless of
> > the options that are provided.
> > What dd does is a *synchronous* I/O (read/write syscalls or
> > pread64/pwrite64 for older kernels).
> > 
> > Whenever the I/O is cached (an output file is opened without
> > O_DIRECT|O_DSYNC flags) or not is orthogonal to whenever it's sync or
> > async.
> 
> It would not surprise me if there are a dozen layers of chip registers, 
> caches, buffers, memory, etc., between a CPU register and whatever device 
> implements
> data storage in a recent to modern x86_64 computer. And, I can only wonder if 
> reading /dev/zero even comes from a CPU register -- it would not surprise me 
> if
> an MMU feature does.
> 
> 
> I was referring to the 'fdatasync', 'fsync', 'dsync', 'sync', and 'nocache' 
> options to dd(1).

You did. These all deal with the various caching aspects.
Several years ago I saw some patches to dd that implemented async I/O,
but AFAIK they were never accepted upstream. May have something with the
fact that the patches in question were written by Oracle employees.


> Given the terse manual page, and a unwillingness to crawl the dd(1)
> and/or kernel code, I can only guess at my understanding of what is
> happening.

There's strace for the lazy ones like you and me ;) One of my favorite
troubleshooting tools for many years.


> But, all of those options seem to imply some opposite of
> asynchronous or buffered I/O as I know it.

No, it's just the wording.

"sync" - you are blocked on each read/write syscall, and there's no way
around it.

"async" - you're not, if you're doing io_submit. You are if you're doing
io_getevents, but life's unfair.

"direct" - you're telling the kernel that you do not consider a write
completed unless it has landed at a persistent storage. You're asking a
kernel to read for you regardless of the state of the kernel's current
page cache.

"cached" - you don't care whenever your write lands to the persistent
storage. Likewise, you don't care if the read comes from the page cache
or the persistent storage.

Most of the I/O your everyday programs do is "cached sync". There are
exceptions to this rule, like apt (dsync writes), or firefox (dsync
writes for sqlite). But to have an async I/O, one usually have to link
against libaio, like mysql or postgres do.


> "The devil is in the details."

Totally agree.

Reco

Re: Could RAM possibly be just 3-4 times faster than bare hdd writes and reads? or, is the Linux kernel doing its 'magic' in the bg? or, ...

[tomas]

On Wed, Jun 17, 2020 at 11:45:53PM +0300, Reco wrote:

[...]

> Long story short, if you need a primitive I/O benchmark, you're better
> with both dsync and nocache.

Thanks for actually looking over dd's shoulder :-)

Cheers
-- t


signature.asc
Description: Digital signature

Re: Could RAM possibly be just 3-4 times faster than bare hdd writes and reads? or, is the Linux kernel doing its 'magic' in the bg? or, ...

[Reco]

Hi.

On Wed, Jun 17, 2020 at 10:33:51PM +0200, to...@tuxteam.de wrote:
> So to test disk write speed, 'dsync' seems the way to go. When dumping
> to a device, there are no metadata (am I right there?), so probably
> again you want 'dsync'.
> 
> I don't know what 'nocache' would do for writing. For reading, it seems
> to make sense to avoid huge files (think a video) uselessly clobbering
> your cache (you're going to look at the blocks once, right?).

Ez.

Conventional dd:

$ strace dd if=/dev/zero of=/tmp/1 bs=1M count=1
openat(AT_FDCWD, "/dev/zero", O_RDONLY) = 3
...
openat(AT_FDCWD, "/tmp/1", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3



dsync dd (note O_DSYNC flag):

$ strace dd if=/dev/zero of=/tmp/1 bs=1M count=1 oflag=dsync
openat(AT_FDCWD, "/dev/zero", O_RDONLY) = 3
...
openat(AT_FDCWD, "/tmp/1", O_WRONLY|O_CREAT|O_TRUNC|O_DSYNC, 0666) = 3



nocache dd (note fadvise64 syscall and the lack of O_DSYNC flag):

$ strace dd if=/dev/zero of=/tmp/1 bs=1M count=1 oflag=nocache
openat(AT_FDCWD, "/dev/zero", O_RDONLY) = 3
...
openat(AT_FDCWD, "/tmp/1", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
...

...
fadvise64(1, 0, 1048576, POSIX_FADV_DONTNEED) = 0


Basically by "dsync" you're telling "I want chunks of this file to be
written to the disk every time I finish waiting write(2) syscall, but
feel free to cache it for other readers anyway", and by "nocache" you're
telling "I need it to evict from the filesystem cache once I close the
file but feel free to cache it before then, and I don't need to wait for
the disk writes every time I call write(2)".

Long story short, if you need a primitive I/O benchmark, you're better
with both dsync and nocache.

Reco

Re: Could RAM possibly be just 3-4 times faster than bare hdd writes and reads? or, is the Linux kernel doing its 'magic' in the bg? or, ...

[tomas]

On Wed, Jun 17, 2020 at 01:23:41PM -0700, David Christensen wrote:

[...]

> I was referring to the 'fdatasync', 'fsync', 'dsync', 'sync', and
> 'nocache' options to dd(1).  Given the terse manual page, and a
> unwillingness to crawl the dd(1) and/or kernel code, I can only
> guess at my understanding of what is happening.  But, all of those
> options seem to imply some opposite of asynchronous or buffered I/O
> as I know it.

FWIW, the info file is more --uh-- informative on those. I copy
the bits which seem related to this thread. Elisions marked with
[...]:

‘oflag=FLAG[,FLAG]...’
 Access the output file using the flags specified by the FLAG
 argument(s).  (No spaces around any comma(s).)

 Here are the flags.  Not every flag is supported on every operating
 system.

 [...]

 ‘dsync’
  Use synchronized I/O for data.  For the output file, this
  forces a physical write of output data on each write.  For the
  input file, this flag can matter when reading from a remote
  file that has been written to synchronously by some other
  process.  Metadata (e.g., last-access and last-modified time)
  is not necessarily synchronized.

 ‘sync’
  Use synchronized I/O for both data and metadata.

 ‘nocache’
  Request to discard the system data cache for a file.  When
  count=0 all cached data for the file is specified, otherwise
  the cache is dropped for the processed portion of the file.
  Also when count=0, failure to discard the cache is diagnosed
  and reflected in the exit status.

  Note data that is not already persisted to storage will not be
  discarded from cache, so note the use of the “sync” options in
  the examples below, which are used to maximize the
  effectiveness of the ‘nocache’ flag.

  Here are some usage examples:

   # Advise to drop cache for whole file
   dd if=ifile iflag=nocache count=0

   # Ensure drop cache for the whole file
   dd of=ofile oflag=nocache conv=notrunc,fdatasync count=0

   # Advise to drop cache for part of file
   # Note the kernel will only consider complete and
   # already persisted pages.
   dd if=ifile iflag=nocache skip=10 count=10 of=/dev/null

   # Stream data using just the read-ahead cache.
   # See also the ‘direct’ flag.
   dd if=ifile of=ofile iflag=nocache oflag=nocache,sync


So to test disk write speed, 'dsync' seems the way to go. When dumping
to a device, there are no metadata (am I right there?), so probably
again you want 'dsync'.

I don't know what 'nocache' would do for writing. For reading, it seems
to make sense to avoid huge files (think a video) uselessly clobbering
your cache (you're going to look at the blocks once, right?).

Cheers
-- tomás


signature.asc
Description: Digital signature