# General FreeBSD desktop workload optimization thread.



## kronisk (Feb 17, 2011)

Hi guys.

I haven't seen any thread anywhere with the purpose stated in the title, albeit I've seen lots of hints scattered around in different posts. That's why I think there's potential for this kind of thread.

This is of course not a ZFS/server optimization thread -- there's plenty of that.

If I'm mistaking, please feel free to post a link the thread/guide.

The scenario I'm shooting for:

The user has already installed and enjoyed FreeBSD, Xorg and Desktop environment.

The user enjoys all the typical desktop things be it:
Graphical work, watching movies, playing native games and/or wine games etc.

The tinker within that user wants to play around with sysctl and/or other features, but need guidance as to what knobs to turn.. probably already has turned on a few knobs, perhaps even things that didn't matter.

Got any advice? Post it here.

I'll of course share what I've found so far (not alot!):

1. Edited make.conf to include CPUTYPE= and CFLAGS= -02 -pipe
I was told the compilation could be optimized by defining those values, making "better/smoother" binaries.

2. I found a post stating the following sysctl values (added to sysctl.conf)

```
# Enhance shared memory X11 interface
kern.ipc.shmmax=67108864
kern.ipc.shmall=32768
```

3. In another post I found this sysctl value:

```
# Increase desktop responsiveness under high CPU use (200/224)
kern.sched.preempt_thresh=224
```
That's all I got so far.

Some might be completely pissed off by the fact, that I'm just blurping out stuff I quite honestly don't understand on any sort of deeper level. Yeh, sorry about that, but it's meant to be a general purpose tinkering/optimization thread where users can find inspiration to try different things. Not a benchmark of each proposed option. If this is completely against forum etiquette, please point me in the right direction.

NB:
Some things could be proposed, that are harmful to the system, so don't forget the common sense.


----------



## SirDice (Feb 17, 2011)

kronisk said:
			
		

> 1. Edited make.conf to include CPUTYPE= and CFLAGS= -02 -pipe
> I was told the compilation could be optimized by defining those values, making "better/smoother" binaries.


Only set CPUTYPE, don't play around with CFLAGS, the defaults are optimized enough.


----------



## xibo (Feb 17, 2011)

Hmmm, let's see.

First, don't set CFLAGS globaly - disabling it will safe you more time bothering why things break than enabling saves runtime: *-march=native -O3 -floop-...* will result in like 10% run time improvement in average on the price of 50% object code size and compile time with gcc-4.4/4.5 (on gentoo linux, never tried it on FreeBSD but i think it'll be the same here), so in order to gain that 10% speed advantage you first have to invest alot more then 10% more compilation time and loading programs from disk also is slow. Furthermore, gcc tends to have it's bugs, and the software being compiled also does, so you will likely have to recompile some packages if you don't compile them with the 'default' flags that trigger the 'right' gcc misbehavior - ah, and you'll lose "support" for FreeBSD if you played with CFLAGS for buildworld/kernel.

Instead, override build tools and flags only for individual ports that you want to optimize more, and can live with them having broken - you can live with broken mplayer, as in the worst case you'll just recompile it taking a few minutes, but you don't want to live with a broken ... libc:


```
.if ${.CURDIR:M*/multimedia/ffmpeg*} || ${.CURDIR:M*/multimedia/vlc*}
  CC=gcc45
  CXX=g++45
#  CFLAGS=-O1 -g
#  WITH_DEBUG=YES
.endif
```

By the way, -pipe is enabled by default on gcc-4, and -O2 is enabled for next to every port (and those who are not enabling it know why!)

Enable soft-updates on any UFS partition that is being written to regularily (enabled by default). Your filesystem access will get faster by doing it, and it'll also help you keeping the filesystem consistent on crashes (which safes you a _lot_ of time). Next, mount any filesystems that are rarely written to (most probably all but the home directory's filesystem and the one containing /var) with readonly access, and disable access time stamping on the write-allowed mounts unless it's needed.

Sacrifice some memory and put /tmp and /var/tmp (just symlink one to the other) on tmpfs. kioslave (kdelib's IO helpers) likes using /tmp for buffers, and it's certainly not the only thing that does. Furthermore if memory gets filled and used by other things, tmpfs can be swapped to virtual memory if not needed to be persistent.

Disable some enabled-by-default-yet-useless-to-you features of your desktop environment. KDE's strigi file indexer for example, will do nothing more then waste time (and produce noice with all it's disk accesses) to most of the KDE users. The most obvious point of tuning might not be FreeBSD related, but it'll still be the most efficient.

The mplayer version from ports seems not to split its work over multiple CPUs (efficiently). VLC does. When playing expensive videos such as BluRays you will notice the difference (if you have a smp system). Also, the VLC backend to kde/qt's phonon is more capable than gstreamer, so you probably will have vlc installed anyways if you have kde.

Atom/ION friends might want to disable all kind of graphical gizmos to begin with. But also, instead of setting up a ridiculous let's say 1920*1080 or 2048*1536 screen and increasing the font size, just leave the screen resolution low and don't increase the font size. Common sense you might think, but I've seen this quite often.

I think the SHM tuning might be interresting... can anyone doing it benchmark it?


----------



## SirDice (Feb 17, 2011)

Don't forget to read tuning(7).


----------



## vermaden (Feb 17, 2011)

> 1. Edited make.conf to include CPUTYPE= and CFLAGS= -02 -pipe
> I was told the compilation could be optimized by defining those values, making "better/smoother" binaries.


The whole FreeBSD 'ecosystem' (both base system and pakcages) are compiled with these:  -O2 -fno-strict-aliasing -pipe as defaults, so You will NOT gain anything, its useless.

I also use these on my 'graphical' systems on /boot/loader.conf file:

```
# boot delay
autoboot_delay=1
beastie_disable=YES

# firefox HTML5 fix
sem_load=YES

# page share factor per proc
vm.pmap.shpgperproc=512

# open files
kern.maxfiles=16384
kern.maxfilesperproc=8192

# avoid additional 128 interrupts per second per core
hint.atrtc.0.clock=0

# do not power devices without driver
hw.pci.do_power_nodriver=3

# reduce sound generated interrupts
hint.pcm.0.buffersize=65536
hint.pcm.1.buffersize=65536
hint.pcm.2.buffersize=65536
hw.snd.feeder_buffersize=65536
hw.snd.latency=7

# ahci power management
# check: dmesg | grep ahcich
hint.ahcich.0.pm_level=5
hint.ahcich.1.pm_level=5
hint.ahcich.2.pm_level=5
hint.ahcich.3.pm_level=5
```


----------



## oliverh (Feb 17, 2011)

@vermaden as far as I know, your SEM line is redundant.



> ```
> options         P1003_1B_SEMAPHORES     # POSIX-style semaphores
> ```



Using CPUTYPE is prone to failure in some circumstances and the performance gain is almost nothing on modern CPUs (apart from ancient CPU-designs like Intel Atom). 

If you're using UFS try something like this:


```
vfs.read_max=32
vfs.ufs.dirhash_maxmem=134217728
```

The defaults of FreeBSD aren't up to date anymore.


----------



## rusty (Feb 17, 2011)

Consider 
	
	



```
vfs.read_max=128
```
 based on 
http://ivoras.sharanet.org/blog/tree/2010-11-19.ufs-read-ahead.html


----------



## kronisk (Feb 17, 2011)

I decided to add most of your loader.conf options just to try it out. Then I wanted to check out if the values were actually changed, and some of them weren't. For instance vm.pmap.shpgperproc=512. Does it change for you? Does this mean that it's an option to compile the kernel with or?


----------



## oliverh (Feb 17, 2011)

Are you experiencing some kind of slowdown? If so, then start optimizing UFS first. I wouldn't experiment with disputable options just for fun.


----------



## kronisk (Feb 17, 2011)

I'm not experiencing slowdown, on the contrary. Everything runs great (had some stuttering in SC2, gone now)

The "hint" entries you have in your loader.conf should be in device.hints.. at least in 8.1


----------



## Galactic_Dominator (Feb 17, 2011)

oliverh said:
			
		

> Using CPUTYPE is prone to failure in some circumstances and the performance gain is almost nothing on modern CPUs (apart from ancient CPU-designs like Intel Atom).



Performance gain is absolutely nothing in nearly every case since the default is native which is gcc autodetecting your CPU type.  You can screw things up if you set it wrong, but you can't gain anything by setting it correctly.


----------



## MarcoB (Feb 18, 2011)

I've put 
	
	



```
vfs.read_max=128
```
 in my sysctl.conf, but after every reboot it switched back to the default 8. How can I make this setting permanent?


----------



## DutchDaemon (Feb 18, 2011)

That *is* the way to make it permanent.


----------



## MarcoB (Feb 18, 2011)

So why is it changed back to 8 every time it reboots?


----------



## Galactic_Dominator (Feb 18, 2011)

MarcoB said:
			
		

> So why is it changed back to 8 every time it reboots?


Only your system can answer that.  Usually it's due to something like a misspelling, or some offending character occurring earlier in the file.  Booting verbose may help identify the issue.


----------



## wblock@ (Feb 18, 2011)

MarcoB said:
			
		

> So why is it changed back to 8 every time it reboots?



It may not be changing at all.  Do you have a linefeed at the end of the sysctl.conf line?


----------



## kronisk (Feb 18, 2011)

It's one of those values you can change on the fly.. So it's easy to check misspellings.
The format of sysctl.conf is


```
vfs.read_max=128
```

and not


```
sysctl vfs.read_max=128
```

.. if you haven't made either of those 2 mistakes I agree it's a bit strange^^


----------



## phoenix (Feb 18, 2011)

kronisk said:
			
		

> I'm not experiencing slowdown, on the contrary. Everything runs great (had some stuttering in SC2, gone now)
> 
> The "hint" entries you have in your loader.conf should be in device.hints.. at least in 8.1



/boot/device.hints should be treated like a defaults file.  Put your overrides into /boot/loader.conf.  device.hints is part of the OS install and will be overwritten by installworld/mergemaster unless you are very careful.  loader.conf is a user-managed file.


----------



## MarcoB (Feb 18, 2011)

wblock said:
			
		

> It may not be changing at all.  Do you have a linefeed at the end of the sysctl.conf line?



Thank you mr. Block, it was a linefeed thing. Didn't know this would make a difference, it wasn't misspelled or something. I changed it on the fly but changed back to 8 at every reboot (@kronisk). Now I'm curious if my system is flying even faster with this setting


----------



## wblock@ (Feb 19, 2011)

MarcoB said:
			
		

> Thank you mr. Block, it was a linefeed thing. Didn't know this would make a difference, it wasn't misspelled or something. I changed it on the fly but changed back to 8 at every reboot (@kronisk). Now I'm curious if my system is flying even faster with this setting



benchmarks/bonnie++ will let you test.  My system did about 121M/sec with vfs.read_max=32, and 0.2% slower with vfs.read_max=128; statistically insignificant.  But that's probably as fast as this single drive can read.

It's a good example.  A lot of optimizations only make a difference on certain hardware, and don't help or actually slow down on other hardware.  Benchmarking is the only way to know for sure.


----------



## kronisk (Feb 20, 2011)

Thank you to everybody who participated in this thread as of yet.

I have now landed on a configuration which I'm very pleased with, and I'm going to post my sysctl.conf and loader.conf hoping someone will find it useful. 

I've also compiled a custom kernel with some options from the PC-BSD kernel (in their wiki they said: "PC-BSDâ€™s kernel has been recompiled with some configuration tweaks to better suit it for desktop use" -- additionally I've stripped the kernel of all modules I'm not using, rendering it quite small.

One should keep in mind, that the values I've selected reflect some trial and error on my particular setup, and it might not work so great for you. My setup is used for a Desktop workload, namely running StarCraft 2 in wine, watching movies yadayada.

sysctl.conf:


```
# $FreeBSD: src/etc/sysctl.conf,v 1.8.34.1.4.1 2010/06/14 02:09:06 kensmith Exp $
#
#  This file is read when going to multi-user and its contents piped thru
#  ``sysctl'' to adjust kernel values.  ``man 5 sysctl.conf'' for details.
#

# Uncomment this to prevent users from seeing information about processes that
# are being run under another UID.
#security.bsd.see_other_uids=0

# Description from tweaks obtained by "sysctl -ad"

# File system tweak
 #Maximum amount of space to use for in-progress I/O
 vfs.hirunningspace=10485760
	
 #Maximum allowed dirhash memory usage
 vfs.ufs.dirhash_maxmem=134217728

 #Cluster read-ahead max block count
 vfs.read_max=128

######################################################

# Kernel tweak
 #Min priority for preemption, lower priorities have greater precedence
 kern.sched.preempt_thresh=200

 #Maximum files allowed open per process
 kern.maxfilesperproc=8192

 #Maximum shared memory segment size
 kern.ipc.shmmax=67108864

 #Maximum number of pages available for shared memory
 #One page is 4096 bytes, thus 256*(256*4096) = 256MB
 kern.ipc.shmall=65536

 #Enable/Disable locking of shared memory pages in core
 kern.ipc.shm_use_phys=1

 #Enable/Disable attachment to attached segments marked for removal
 kern.ipc.shm_allow_removed=1

########################################################

# Sound tweak
 #linux mmap compatibility (-1=force disable 0=auto 1=force enable)
 hw.snd.compat_linux_mmap=1

########################################################

# Virtual memory tweak
 # See tuning(7)
 vm.overcommit=2
```

... and loader.conf:


```
nvidia_load="YES"
sem_load="YES"

# Kernel tweaks
 #Pipe KVA limit, see tuning(7) for more info.
kern.ipc.maxpipekva=25165824
 
 #Maximum number of files
 kern.maxfiles=16384

 #Number of segments per process
 kern.ipc.shmseg=256

##################################################

# Virtual memory tweak
 #Are large page mappings enabled?
 vm.pmap.pg_ps_enabled=1
 
 #Page share factor per proc
 vm.pmap.shpgperproc=512

##################################################

# Misc. tweak

# Sound interruption reduction
hw.snd.feeder_eq_exact_rate=48000
hw.snd.latency=7
hint.pcm.0.buffersize=65536

# Avoid additional 128 interrupts per second per core
hint.atrtc.0.clock=0
```


----------



## vermaden (Feb 20, 2011)

@kronisk

Does it feel better/more responsive with these settings?


----------



## wblock@ (Feb 20, 2011)

vermaden said:
			
		

> Does it feel better/more responsive with these settings?



Careful: Hawthorne effect.

After changing that readmax setting, I could swear buildworlds are going faster.  But the actual times show it's about the same.


----------



## vermaden (Feb 20, 2011)

wblock said:
			
		

> After changing that readmax setting, I could swear buildworlds are going faster.  But the actual times show it's about the same.



I was thinking rather about responsiveness, especially under load, that is hard to measure, and its very subjective.


----------



## kronisk (Feb 21, 2011)

wblock said:
			
		

> Careful: Hawthorne effect.
> 
> After changing that readmax setting, I could swear buildworlds are going faster.  But the actual times show it's about the same.



I see your point, but one effect of my customization is indisputable:
When I played StarCraft 2 from a clean install, there was a 2 second spike (which seemed sound generated, but I'm not so sure now) whenever a building finished. Those are like 90% gone now, but when they occur they are well under 1000ms!

I also tried commenting out all my changes, reboot and play a game of starcraft 2, and the spikes returned. What has the biggest impact were the shared memory tweaks. I did not go about the commenting/uncommenting scientifically as I chose settings in chunks I felt like.  

As for the rest of the system (compiling, browsing etc.) it's not noticeably faster -- heck, it was running superb even before I started customizing.

I will try some benchmark later today. Can you recommend any? Perhaps some of my description above inspired you to say: Ye, THAT one!^^


----------



## kronisk (Feb 23, 2011)

In my further quest for desktop optimization, I looked into the PC-BSD sources. And, oh man, is trac awesome!! Anyway they added some options to the kernel:


```
#
# PCBSD -- Generic kernel configuration file for PCBSD 8
#

include GENERIC

ident		PCBSD

# Include atapicam support
device          atapicam        # ATAPI Cam Support

# Added support for pf / altq
device          pf
device          pflog
device          pfsync
options         ALTQ
options         ALTQ_CBQ
options         ALTQ_RED
options         ALTQ_RIO
options         ALTQ_HFSC
options         ALTQ_CDNR
options         ALTQ_PRIQ
options         ALTQ_NOPCC

# AppleTalk Support
options         NETATALK

# x86 real mode BIOS emulator, required by atkbdc/dpms/vesa
options         X86BIOS
options		SC_PIXEL_MODE
```

but more importantly, the following entries in /boot/loader.conf and /etc/sysctl.conf respectively


```
# Kernel Options
kern.ipc.shmseg=1024
kern.ipc.shmmni=1024
kern.maxproc=10000
```


```
# Disable the system speaker
hw.syscons.bell=0

# Disable coredump
kern.coredump=0
	
# Up the maxfiles to 4x default
kern.maxfiles=49312
	
# Allow users to mount CD's
vfs.usermount=1

# Enable more sound channels
dev.pcm.0.play.vchans=4
dev.pcm.0.rec.vchans=4
```

I thought I'd share with you since these are "certified tweaks" if you will for desktop use as stated in the pc bsd wiki.

Cheers!


----------



## ckester (Feb 23, 2011)

Some random thoughts re this thread:

On the whole, I'm not keen on applying tweaks where I don't understand what they do.

But even if I do understand them, I don't think it's wise to modify the default install without a good reason -- which means that the FIRST thing to do is to profile the system and identify any bottlenecks.  There's not much sense in optimizing something that has little impact on overall performance anyway.  Do you know where your system is spending the most time?  Optimize THAT.

Old programmer's motto: premature optimization is the root of all evil.  (It might have been Ritchie or Pike who said that. One of those Unix pioneers anyway.)

Another classic mistake is applying a bunch of tweaks all at once, so you can't tell which one (if any) made any noticeable difference.

Disk access and the filesystem can be a bottleneck, but it's not always.  I wouldn't assume that it is, not without some stats to support that conclusion.

You should approach optimization as an exercise in troubleshooting.  The most effective methods follow a similar logic.  Learn to use vmstat, top, gstat and similar tools.  They're not just for servers, you can use them on a desktop too.


----------



## danbi (Feb 23, 2011)

ckester, good points. 

I would like to add, that for example 'poor file system performance' is rarely caused by the filesystem performance as such or the disks performance as such. In most 'desktop' cases I found out the filesystem gets hit by badly written, or rather, improperly ported software, devel/gamin comes to mind (I know, it can be configured properly, but "out of the box" is not).

On the other hard, current computers are way more powerful than the needs of almost any desktop application.

By the way, I fail to understand what use can a desktop system have of pf/altq.


----------



## xibo (Feb 23, 2011)

ckester said:
			
		

> Do you know where your system is spending the most time?  Optimize THAT.



My desktop spends absolutely most of it's time with doing nothing ( waiting for input ).
I guess that is troublesome...



			
				danbi said:
			
		

> I fail to understand what use can a desktop system have of pf/altq.


You need it if you want to use your desktop as (most probably NAT-ing) internet-router for other computers of yours. Other than that, i don't see a point, either.


----------



## phoenix (Feb 23, 2011)

Packet filter on the local host can be useful, if you want to prevent incoming access from other systems, or restrict incoming access to specific systems, or if you want to block outgoing ports that you don't use.

That last part is most useful on non-Unix systems where malware can use up a lot of network bandwidth, and gave rise to the whole Personal Firewall app category.


----------



## ckester (Feb 23, 2011)

xibo said:
			
		

> My desktop spends absolutely most of it's time with doing nothing ( waiting for input ).
> I guess that is troublesome...



Ha, good one!

Obviously, I meant the things the system is doing when it isn't waiting on the slow human at the keyboard.   We usually don't perceive that kind of idling as a performance problem.  

Our computers, if they were sentient, would probably have a different opinion.  All the more reason to take a thoughtful approach to performance tweaking -- someday the tables might be turned and the computers might be tweaking us.  If so, I'd like them to remember how respectful and uncapricious I was when I was in charge.


----------



## kronisk (Feb 25, 2011)

lulz were shared 8)~... hopefully Bender isn't an accurate portrait of the AI to come... what with the KILL ALL HUMANS and what not^^


----------



## xibo (Feb 25, 2011)

phoenix said:
			
		

> Packet filter on the local host can be useful, if you want to prevent incoming access from other systems, or restrict incoming access to specific systems, or if you want to block outgoing ports that you don't use.
> 
> That last part is most useful on non-Unix systems where malware can use up a lot of network bandwidth, and gave rise to the whole Personal Firewall app category.



The way I see it, the policy of the network's gateway should be good enough for any host of that network, and I'd rather allow or block a certain range of services to a certain range of hosts on the gateway than to configure each of the hosts' firewalls.

If the undesired traffic originated from within the own network, fixing the source would prove more efficient then walking/rlogin-ing around and blocking it from each and any host, too.

I don't know about the configurability of the "router" devices you get from ISPs these days, but even if they aren't able to filter the traffic properly I'd replace them with an old PC for firewalling - the PC could do dns- and webcaching which most "router"-s probably can't, too, and webcaching *is* worth the effort.

About the malware: Every time I get back home from the university kde's dns caching deamon would easily take all the bandwidth of my ISDN uplink to keep it's cache alife, even when there's no outgoing connection or even a browser window running. 

Well, in the end however i guess the presence of a firewall isn't a real performance hog for a desktop machine, since desktop's don't get dozens of megabytes of traffic per second to filter and don't do any expensive IDS triggered auto-firewaling, firewall-backed dynamic traffic shaping, or any other expensive firewall-related tasks either.



			
				kronisk said:
			
		

> lulz were shared 8)~... hopefully Bender isn't an accurate portrait of the AI to come... what with the KILL ALL HUMANS and what not^^


hopefully xibo isn't accurate about his portrait of DutchDeamon to have deleted that post of yours even before xibo clicked the "submit reply" button.


----------



## danbi (Feb 25, 2011)

I was particularly curious about the usefulness of ALTQ in a desktop, or a server in general. ALTQ is an addition to network drivers that adds prioritization support. If it's useful for non-router usage, perhaps it should be enabled in the FreeBSD GENERIC kernel by default


----------



## xibo (Feb 25, 2011)

danbi said:
			
		

> I was particularly curious about the usefulness of ALTQ in a desktop, or a server in general. ALTQ is an addition to network drivers that adds prioritization support. If it's useful for non-router usage, perhaps it should be enabled in the FreeBSD GENERIC kernel by default



On Windows OS, where that functionality isn't straightforwardly accessible, I would say that ALTQ would undoubtedly be useful. For example, you might be running ftp and BitTorrent transactions, downloading the new windows seven service pack, having your spy-ware report about you and all that while playing video games in the internet, so you rate limit everything other then your game in order to get acceptable latencies.

Some of the download software can be configured to cause only a certain amount of traffic over some time, but many others can't, and when configuring them you rarely consider that you might eventually run multiple of them at the same time.

Of cause, "getting more bandwidth" would also fix the problem ( well, not really, but we should try! )

Unfortunately, there aren't many video games for FreeBSD, and a poor latency in rlogin, telnet, ssh, and so on is normaly not that bad that it would render them unusable. When they become, there's usually other hosts in your network helping to destroy the quality of service, and then you'll need the gateway to do the traffic shaping again - rather than the clients/hosts.

IMO router machines are a primary target for FreeBSD, so it should be in GENERIC anyway.


----------



## DutchDaemon (Feb 25, 2011)

xibo said:
			
		

> hopefully xibo isn't accurate about his portrait of DutchDeamon to have deleted that post of yours even before xibo clicked the "submit reply" button.



Hopefully talking about oneself in the third person is not an indication of the propensity to utter unsubstantiated allegations.


----------



## CuatroTorres (Feb 23, 2021)

Tell me if it's not allowed to revive such old threads; at least I didn't find anything in the forum rules.

I was with a frozen desktop on Linux due to the problem of copying files to an usb drive: The pernicious USB-stick stall problem.

In FreeBSD-13.0-BETA3-amd64 I get a little improvement, the mouse doesn't get stuck and if I open a medium size application, such as Abiword, it takes a little time to respond, while an application like Firefox lags too much, sometimes until the copy is finished.

I wonder if these suggestions are valid today and how I could improve I/O and the use of limited RAM (2GB). I'm using the Xfce desktop.


----------



## eternal_noob (Feb 23, 2021)

CuatroTorres said:


> the use of limited RAM (2GB)




Limited? I run a machine with half of that:

```
root@xxx:~ # grep memory /var/run/dmesg.boot
real memory  = 1077936128 (1028 MB)
avail memory = 959512576 (915 MB)
agp0: aperture size is 256M, detected 32764k stolen memory
```



CuatroTorres said:


> I'm using the Xfce desktop


I can recommend x11-wm/openbox on low-end machines like mine (stand-alone, no DE). Runs very smooth.

OpenBox: It runs in about 7MB of memory
Xfce4: It runs in about 70MB of memory









						A Memory Comparison of Light Linux Desktops
					

After I install a new version of Linux, I usually take a good look at the screen. Does it have a task bar? Can I find my window after it was minimized? The direction some desktops are going is not …




					l3net.wordpress.com
				




In addition, i run the i386 variant of FreeBsd because it has a lower memory footprint than the amd64 variant. (Too bad i386 will be demoted to tier 2 in 13.x)


----------



## vermaden (Feb 24, 2021)

freebsd_noob said:


> In addition, i run the i386 variant of FreeBsd because it has a lower memory footprint than the amd64 variant. (Too bad i386 will be demoted to tier 2 in 13.x)


It will not have bigger impact on users as freebsd-update(8) and pkg(8) will be working as usual (binary upgrades and packages).

Its just bugs that will be treated less 'critically' in i386 now.

... and i386 is really old ... I mean Pentium M chips are from 2003 ... that is 18 years ago 

Of course I with that i386 will remain supported on FreeBSD with freebsd-update(8) and pkg(8) upgrades and packages.


----------



## Deleted member 30996 (Feb 24, 2021)

CuatroTorres said:


> ...how I could improve I/O and the use of limited RAM (2GB). I'm using the Xfce desktop.



Dump the DE for the WM of your choice. I like x11-wm/fluxbox.

I use editors/leafpad for everything expect when at the login terminal, then it's `ee`.

Trying out sysutils/gkrellm2 for meters so you can monitor what's going on with your CPU and Memory would be my suggestion. It looks nice, has 180 skins to do it, does a good job and doesn't take up much resources watching them.


----------



## Mjölnir (Feb 24, 2021)

CuatroTorres said:


> I was with a frozen desktop on Linux due to the problem of copying files to an usb drive: The pernicious USB-stick stall problem.  In FreeBSD-13.0-BETA3-amd64 I get a little improvement, the mouse doesn't get stuck and if I open a medium size application, such as Abiword, it takes a little time to respond, while an application like Firefox lags too much, sometimes until the copy is finished.  I wonder if these suggestions are valid today and how I could improve I/O and the use of limited RAM (2GB). I'm using the Xfce desktop.


I found only one sysctl(8) knob mentioned a decade ago that is not available today.  IMHO the recommendations from tuning(7), espc. concerning UFS, are still valid.  I'd try to disable _vfs.vmiodirenable_ (loader.conf(5)) to have more RAM for applications, and only enable back if that results in a significant slowdown when you use the desktop.  You may want to insert the I/O scheduler gsched(8) with my rc(8) script.  It served me well for years when I had an UFS on a gjournal(8)'ed disk.  IMHO that's preferable to the standard UFS journal.  See the article in /usr/local/share/doc/freebsd.


----------



## eternal_noob (Feb 24, 2021)

vermaden said:


> It will not have bigger impact on users as freebsd-update(8) and pkg(8) will be working as usual (binary upgrades and packages).


Is that really the case? I've read that `freebsd-update` only works for tier 1 architectures?


----------



## vermaden (Feb 24, 2021)

freebsd_noob said:


> Is that really the case? I've read that `freebsd-update` only works for tier 1 architectures?


Yes, but as i386 WAS TIER 1 architecture the explanation from FreeBSD developers I got that the freebsd-update(8) binary upgrades and pkg(8) packages will will work despite being TIER 2 architecture.


----------



## SirDice (Feb 24, 2021)

I think this is the first architecture ever (for FreeBSD at least) that got demoted from tier 1 to tier 2. But as vermaden says, the whole infrastructure for building the patches (freebsd-update(8)) and pkg(8) was already in place and working. They're not going to remove that. Things are different for architectures that moved up from 3 to 2 (and eventually maybe even tier 1). Then there's no infrastructure in place yet and that would need to be set up first.


----------

