Feedback please: foundation of a laptop and desktop work group

C

cmoerz

We - a group of people involved with the FreeBSD community - would like to propose the formation of a new working group dedicated to improving the functionality and usage of FreeBSD on desktop and laptop environments.

Objective

The primary goal of this working group is to enhance the user experience for FreeBSD on desktops and laptops. This includes, but is not limited to, improving hardware compatibility, refining user interfaces, and ensuring seamless integration of applications and services.

The FreeBSD Foundation has recently initiated efforts to improve laptop use and wireless drivers, making this an opportune moment to bring together our collective expertise and enthusiasm to further these advancements.

Who Should Participate?

We welcome participation from all members of the FreeBSD community, including:

  • Regular users who can provide valuable feedback on their experiences and pain points.
  • Developers who can contribute code and technical expertise.
  • Port maintainers who can ensure that applications run smoothly on FreeBSD.
  • Anyone with an interest in enhancing FreeBSD's desktop and laptop environments.
Structure

The working group will be open to anyone interested in joining. We plan to hold regular bi-monthly calls to discuss progress, share ideas, and coordinate efforts. These calls will provide a platform for collaboration and knowledge sharing among all participants.

Initial Call

Our first call is tentatively scheduled for mid-December. This will give everyone ample time to sign up and mark their calendars. During this initial call, we will outline our objectives, discuss potential projects, and establish a roadmap for our efforts.

Feedback and Ideas

We are eager to hear your thoughts on what this working group could or should accomplish. Please share your ideas, suggestions, and any areas you believe we should focus on. Your input is invaluable in shaping the direction and success of this initiative.

Let's work together to make FreeBSD an even better platform for desktop and laptop users!
 
cmoerz said:
Here's the wiki link. Please keep in mind - this is only a limited draft and work in progress. It's intentionally left vague to allow for inputs and feedback from the community, including through this post.
Click to expand...
I'm interested and might contribute to a X.org graphics config autodetection system that covers various common machines. It's now a bunch of bash scripts that's able to start X in more than VESA on several HP and Dell workstations, some with a graphics card added. Goal is to avoid manual configuration per system. 1 problem is that I can't have them all at home for testing.
 
That sounds great! That would certainly make a very useful contribution!

I'm working on getting an official mailing list set up. Once we have that set up, we should be able to schedule a date for a "maiden call".
 
MG said:
It's now a bunch of bash scripts that's able to start X in more than VESA on several HP and Dell workstations, some with a graphics card added. Goal is to avoid manual configuration per system.
Click to expand...
Nice. I have been thinking of similar but it sounds like you are ahead of me. The difference is I was thinking of a script that instructs the user to carry out the tasks and understand the process. I.e the following output:

Oh dear, I detected an AMD or Intel GPU and yet it looks like you forgot to install drm-kmod. Run the following command:
Click to expand...
Oh dear, it looks like you installed the wrong NVIDIA driver for your GPU pci identifier. Run the following commands:
Click to expand...
Oh dear, it looks like you don't have a valid .xinitrc. To fix this, create the files containing the following for a simple test:
Click to expand...

Albeit, perhaps less condecending haha.
 
Just an idea, but scheduler guys would be strongly wanted here.

Current default sced_ule seems to focus on server workloads and known not to be good enough at desktop/laptop workloads. For example, kern.sched.preempt_thresh is too low by default and the default of (I've lost track with, but heard from someone) PC-BSD, 224, works much better on responding to user interactions for desktop/laptop use cases.
 
T-Aoki said:
.sched.preempt_thresh is too low by default
Click to expand...
So what? Set it to any value you like. I am using 162 for servers and 80 for desktops. And I have the bug in the scheduler patched away. Nothing more will happen, because whenever I get some people to look at the bug and probably get it fixed, soon some gang of desktop users appear and start their "not good enough" chant & invocation and disable any constructive discussion. :( (yes I'm pissed)
 
PMc said:
So what? Set it to any value you like. I am using 162 for servers and 80 for desktops. And I have the bug in the scheduler patched away. Nothing more will happen, because whenever I get some people to look at the bug and probably get it fixed, soon some gang of desktop users appear and start their "not good enough" chant & invocation and disable any constructive discussion. :( (yes I'm pissed)
Click to expand...
But average desktop/laptop users coming from other OS'es wouldn't know this. Any of auto-tuning on runtime, selection of workloads on install or brand-new scheduler for desktop/laptop would be wanted.
 
T-Aoki said:
But average desktop/laptop users coming from other OS'es wouldn't know this. Any of auto-tuning on runtime, selection of workloads on install or brand-new scheduler for desktop/laptop would be wanted.
Click to expand...
Absolutely that is the idea of the plugable scheduler. Go for it.
I for my part would rather have the known pathological behaviour removed from the current scheduler. I never got around to really look into that patch, but it seems the original author has provided a patch that seems to address the same problematic behaviour as I have tried to fix. So there is really a measurable problem.
For the desktop issues however ...
cracauer@ said:
Scheduler differences are hard to measure, though. Especially the interactive reactivity.
Click to expand...
... one would need reproducible testcases, which indeed is not easy.
 
I wonder how Linux tests their various preemption models (server, desktop etc). There must be a lot of debating with 4 models in the kernel right now. Do they use numbers for that?
 
I guess measuring interactivity is quite difficult.
And I also recalled "1 second rule" on OS/2, which was not achieved in many cases.
It was, if I recall correctly, "Any application should (shall?) resopnd with user interaction in 1 second, in any form.".
So a question "Are you encounterd any situation that something does not respond your interaction (including command line and mouse clicks) in one second? If yes, what jobs (foreground and background) are running at the moment?" could be a (quite rough) candidate for measurement.
 
T-Aoki said:
I guess measuring interactivity is quite difficult.
And I also recalled "1 second rule" on OS/2, which was not achieved in many cases.
It was, if I recall correctly, "Any application should (shall?) resopnd with user interaction in 1 second, in any form.".
So a question "Are you encounterd any situation that something does not respond your interaction (including command line and mouse clicks) in one second? If yes, what jobs (foreground and background) are running at the moment?" could be a (quite rough) candidate for measurement.
Click to expand...

In modern times most of those > 1 sec reaction times have nothing to do with the CPU scheduler in the narrow sense. Mostly lack of RAM, or waiting on I/O on a disk that is busy with something else. Or both, as in pagein.

That doesn't mean the scheduler is not responsible for making the desktop feel snappy. But what we are looking at here are delays in the centisecond range.
 
There are some plans for the scheduler, see Status Report. Probably not the final fix for desktop use, but I think there's a lot more to that than just interactivity. There's also multimedia stuff you want to play without hiccups, have to weigh that in. And on a typical modern multiprocessor machine the wait for IO dwarfs any CPU scheduling problem, how about IO scheduling?
 
noise said:
but I think there's a lot more to that than just interactivity.
Click to expand...

Yeah..

Drivers & Firmware model
Power Management
ACPI Integration
Service Management (rc.d is slow and adhoc for desktop/laptop)
I/O Scheduling
Inter-process Communication

..and that's just touching the kernel.

Oh, and applications!

By all means, have fun shoehorning a server/embedded system into a desktop.

Good luck!
 
Beastie7 said:
By all means, have fun shoehorning a server/embedded system into a desktop.
Click to expand...
You're making a very valid point - FreeBSD is not going to turn into a "desktop" operating system any time soon. Then again, I imagine there's many ways in which it would become easier and a better experience in the desktop and laptop space.

It's a question of setting focus points and that's where a platform like the suggested working group could help, I imagine. Simplifying knowledge exchange and documenting things in the process would be a great side effect.

The suggestions and improvement points in this thread are great input, in my opinion. So thank you to all of you for bringing your inputs and viewpoints!
 
cracauer@ said:
Excellent question. That's why I'm saying that just messing with the CPU scheduler isn't all that is needed for better interactive "feel".
Click to expand...
Yes, I/O including memory/cache bandwidth would also matter. Not limited with CPU scheduler.
But CPU scheduler has something (indirectly) to do with it, too, by which thread (including kernel threads, but maybe not ithreads for safety) to be prioritized.
The questions I've posted would help determining which area is essential for the case.
 
I wonder whether I could notice the desktop feel difference that people are aiming for by setting Linux to server-optimized preemption and use the most un-desktoppy CPU and I/O scheduler there.
 
High enough (say, overkilling) CPU, memory (both bandwidth and amount), I/O throughput without any bottleneck would hide the interactivity issues, with the cost of expenses/budgets ;) .
 
T-Aoki said:
High enough (say, overkilling) CPU, memory (both bandwidth and amount), I/O throughput without any bottleneck would hide the interactivity issues, with the cost of expenses/budgets ;) .
Click to expand...

I could use a really old Stinkpad :) Have plenty of those. I just want to get a feel for what people mean.

I also think that memory bandwidth probably doesn't matter. And memory amount should very sharply ruin the experience when too low, overriding all other factors.
 
T-Aoki said:
Just an idea, but scheduler guys would be strongly wanted here.

Current default sced_ule seems to focus on server workloads and known not to be good enough at desktop/laptop workloads. For example, kern.sched.preempt_thresh is too low by default and the default of (I've lost track with, but heard from someone) PC-BSD, 224, works much better on responding to user interactions for desktop/laptop use cases.
Click to expand...
Does this really make a difference? Sometimes I have the compiler pull down the speed of my browser music. Is that what you mean? Nice -20 firefox might help but I didn't try it yet. It requires extreme circumstances like 50 cc threads in a batch while almost out of RAM. That's not normal use anyway
 
You must log in or register to reply here.
Back
Top