atom feed11 messages in org.freebsd.freebsd-currentJunior Kernel Hacker Task: M_ZERO
FromSent OnAttachments
Poul-Henning KampOct 20, 2000 12:12 pm 
Robert DrehmelOct 20, 2000 6:08 pm 
Andrea CampiOct 21, 2000 6:15 am 
Garrett RooneyOct 21, 2000 6:48 am 
David MaloneOct 21, 2000 12:16 pm 
Poul-Henning KampOct 21, 2000 10:06 pm 
David MaloneOct 22, 2000 10:54 am 
Jesper SkriverOct 22, 2000 12:07 pm 
David MaloneOct 22, 2000 2:47 pm 
Peter DufaultOct 22, 2000 3:23 pm 
Peter van DijkOct 22, 2000 3:31 pm 
Subject:Junior Kernel Hacker Task: M_ZERO
From:Poul-Henning Kamp (ph@freebsd.org)
Date:Oct 20, 2000 12:12:02 pm
List:org.freebsd.freebsd-current

I have introduced the M_ZERO flag to the kernel malloc, which provides the service to bzero() the memory allocted.

In the kernel sources, the archetypical change to use this facility looks like this:

Old code: databuf = malloc(length, M_DEVBUF, M_WAITOK); bzero(databuf, length);

New code: databuf = malloc(length, M_DEVBUF, M_WAITOK | M_ZERO);

Short term the benefit is less clutter in the code and a smaller cache footprint of the kernel.

Long term, this will allow us to optimize malloc(9) by allocating from a pool of memory which is zero'ed whenever the cpu is idle.

If anybody is looking for a simple task to perform in the FreeBSD kernel: this is it.

A quick grep tells me that there are at least 91 files in the src/sys tree which could use this flag to simplify and optimize the code.

The ground rules for such a cleanup are:

Respect the style of the source file.

Don't make unrelated changes: If you spot other issues with the code as you read it, make a separate diff for those issues.

Bundle the patches at administrative boundaries: a directory at a time, a driver at a time etc etc.

Submit changes to the maintainer of the file (if any) or with send-pr.

Junior committers are encouraged to review and commit these PR's as they arrive

To Unsubscribe: send mail to majo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message