For all Asus Zenbook users or anyone interested about Zenbook laptops
and FreeBSD I did put together some notes. This is work in progress.
http://systemdatarecorder.blogspot.fi/2014/05/asus-zenbook-and-freebsd-11.html
If there are users on this config please send me updates about your config
John, the changes are good.
The 'trickling' but still not idle processes now show up as they should.
However, it has exposed one quirk in the display:
Sorting is done by WCPU followed by total processor time.
Processes which aren't idle (but are using so little cpu it shows as 0.00%)
show
On Sunday, May 25, 2014 3:11:05 am Kubilay Kocak wrote:
On 24/05/2014 7:22 AM, Allan Jude wrote:
On 2014-05-23 16:05, John Baldwin wrote:
Right now, when top is set to not display idle processes or threads, it
only
displays processes or threads that are currently in a runnable state or
On Wednesday, May 28, 2014 12:11:30 am Jia-Shiun Li wrote:
On Sat, May 24, 2014 at 6:38 PM, Tim Bishop tim-li...@bishnet.net wrote:
On Fri, May 23, 2014 at 09:03:12PM -0600, Alan Somers wrote:
Yeah, I think so. It seems like a GENERIC kernel ought to be able to
handle the biggest commonly
On Wednesday, May 28, 2014 8:20:35 am Jamie Landeg-Jones wrote:
John, the changes are good.
The 'trickling' but still not idle processes now show up as they should.
However, it has exposed one quirk in the display:
Sorting is done by WCPU followed by total processor time.
Processes
On Friday, May 23, 2014 4:39:39 pm Poul-Henning Kamp wrote:
In message 201405231605.26312@freebsd.org, John Baldwin writes:
In essence, top will consider any thread that has run on a CPU
since the last update as non-idle.
Sounds a lot more usable than the current heuristic.
Hey,
I wonder if there is or there are any plans to provide an official repo
suitable for a typical non-desktop-installation, i.e. with
WITHOUT_QT4=true
WITHOUT_X11=true
set during poudriere builds. Default options for some graphic related
ports like graphics/gd unfortunally litter all my
On 28 May 2014 06:56, John Baldwin j...@freebsd.org wrote:
Userland cpusets only default to 128 (CPU_MAXSIZE in sys/_cpuset.h).
Changing MAXCPU to even 128 is unfortunately a potential KBI change since it
changes the size of 'cpuset_t'. We can certainly bump these in HEAD for 11,
but we
On Wednesday, May 28, 2014 1:51:28 pm Adrian Chadd wrote:
On 28 May 2014 06:56, John Baldwin j...@freebsd.org wrote:
Userland cpusets only default to 128 (CPU_MAXSIZE in sys/_cpuset.h).
Changing MAXCPU to even 128 is unfortunately a potential KBI change since it
changes the size of
On 28 May 2014, at 18:10, Dirk Engling erdge...@erdgeist.org wrote:
Hey,
I wonder if there is or there are any plans to provide an official repo
suitable for a typical non-desktop-installation, i.e. with
WITHOUT_QT4=true
WITHOUT_X11=true
set during poudriere builds. Default
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Hi,
I get random reboots with revision r266546 (Make iwn(4) able to get
itself back into working condition after fatal firmware error
happens. Previously it was neccessary to reset it manually, using
/etc/rc.d/netif restart.).
I encounter that on
Wiadomość napisana przez Hannes Mehnert w dniu 28 maj 2014, o godz. 23:27:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Hi,
I get random reboots with revision r266546 (Make iwn(4) able to get
itself back into working condition after fatal firmware error
happens. Previously it was
On 28 May 2014, at 17:10, Dirk Engling erdge...@erdgeist.org wrote:
I wonder if there is or there are any plans to provide an official repo
suitable for a typical non-desktop-installation, i.e. with
There aren't currently any plans, but we're now bringing online the
infrastructure for
Hey Guys,
How does kQueue performs over select with netmap ?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
On 2014-05-28 16:44, David Chisnall wrote:
On 28 May 2014, at 17:10, Dirk Engling erdge...@erdgeist.org wrote:
I wonder if there is or there are any plans to provide an official
repo suitable for a typical non-desktop-installation, i.e. with
There aren't currently any plans, but we're now
TB --- 2014-05-28 21:40:52 - tinderbox 2.22 running on freebsd-current.sentex.ca
TB --- 2014-05-28 21:40:52 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE
FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64
TB ---
TB --- 2014-05-28 21:40:52 - tinderbox 2.22 running on freebsd-current.sentex.ca
TB --- 2014-05-28 21:40:52 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE
FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64
TB ---
On 29.05.2014 03:04, Fred Pedrisa wrote:
Hey Guys,
How does kQueue performs over select with netmap ?
You are asking for a comparison between apples and oranges. Netmap is an
API for high performance access to the low-level features of modern
NICs. It works on batches of frames in hardware
Hello,
Yes, but kqueue support was added in recent commits as it says in the netmap
changelog, is there any advantage ?
-Mensagem original-
De: owner-freebsd-curr...@freebsd.org
[mailto:owner-freebsd-curr...@freebsd.org] Em nome de Jan Bramkamp
Enviada em: quinta-feira, 29 de maio de
The advantage is being able to include it in the rest of a kqueue IO
loop where it's doing other things.
-a
On 28 May 2014 20:53, Fred Pedrisa fredhp...@hotmail.com wrote:
Hello,
Yes, but kqueue support was added in recent commits as it says in the netmap
changelog, is there any advantage ?
Hello,
Ok, but in practice, is there any performance gain by moving from select to
kQueue implementation ? Or is it not significant at all ?
-Mensagem original-
De: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] Em nome de Adrian
Chadd
Enviada em: quinta-feira, 29 de maio de
On 28 May 2014 21:48, Fred Pedrisa fredhp...@hotmail.com wrote:
Hello,
Ok, but in practice, is there any performance gain by moving from select to
kQueue implementation ? Or is it not significant at all ?
-Mensagem original-
De: adrian.ch...@gmail.com
If your netmap thread(s) just have one or two FDs in some low range
(say, under FD 8 or 10) - no.
If you have a whole bunch of active FDs and your netmap threads get
FDs that are high - then yes. select() operates on a bitmap of FD
numbers. So if your netmap FD is like, FD 8 and it's the highest
Hello,
There are 4 threads, and a total of 32 FDs. What do you think ?
-Mensagem original-
De: owner-freebsd-curr...@freebsd.org
[mailto:owner-freebsd-curr...@freebsd.org] Em nome de Adrian Chadd
Enviada em: quinta-feira, 29 de maio de 2014 01:52
Para: Fred Pedrisa
Cc: freebsd-current;
On Thursday 29 May 2014 01:57:38 Fred Pedrisa wrote:
Hello,
There are 4 threads, and a total of 32 FDs. What do you think ?
I think it is time for you to try it and find out...
I suspect it wouldn't make much difference at all if you just implement select
semantics with kqueue.
Hi, Guys.
How can I adjust a certain thread to have the maximum system priority in the
scheduler ?
I've tried doing it this way :
/* Set thread priority. */
if
are you doing this all as root?
-a
On 28 May 2014 22:12, Fred Pedrisa fredhp...@hotmail.com wrote:
Hi, Guys.
How can I adjust a certain thread to have the maximum system priority in the
scheduler ?
I've tried doing it this way :
/*
what he said.
-a
On 28 May 2014 22:02, Peter Wemm pe...@wemm.org wrote:
On Thursday 29 May 2014 01:57:38 Fred Pedrisa wrote:
Hello,
There are 4 threads, and a total of 32 FDs. What do you think ?
I think it is time for you to try it and find out...
I suspect it wouldn't make much
Hello,
Yes.
-Mensagem original-
De: owner-freebsd-curr...@freebsd.org
[mailto:owner-freebsd-curr...@freebsd.org] Em nome de Adrian Chadd
Enviada em: quinta-feira, 29 de maio de 2014 02:18
Para: Fred Pedrisa
Cc: freebsd-current
Assunto: Re: Thread Scheduler Priority
are you doing this
29 matches
Mail list logo
