apply(1) small cleanup
Make a Private function private and other things. ok?
-mark
Index: apply.c
===
RCS file: /cvs/src/usr.bin/apply/apply.c,v
retrieving revision 1.24
diff -u -p -r1.24 apply.c
--- apply.c 27 Oct 2009 23:59:35 - 1.24
+++ apply.c 26 Apr 2011 09:40:48 -
@@ -44,8 +44,8 @@
#include string.h
#include unistd.h
-void usage(void);
-intmysystem(const char *);
+static voidusage(void);
+static int mysystem(const char *);
int
main(int argc, char *argv[])
@@ -179,8 +179,7 @@ main(int argc, char *argv[])
/* Run the command. */
if (debug)
(void)printf(%s\n, c);
- else
- if (mysystem(c))
+ else if (mysystem(c))
rval = 1;
}
@@ -191,14 +190,14 @@ main(int argc, char *argv[])
}
/*
- * system --
+ * mysystem --
* Private version of system(3). Use the user's SHELL environment
* variable as the shell to execute.
*/
-int
+static int
mysystem(const char *command)
{
- static char *name, *shell;
+ static const char *name, *shell;
pid_t pid;
int pstat;
sigset_t mask, omask;
@@ -235,7 +234,7 @@ mysystem(const char *command)
return(pid == -1 ? -1 : pstat);
}
-void
+static void
usage(void)
{
(void)fprintf(stderr,
Rolling Stones y Mick Jagger - Discografía y Pendrive de Regalo - (81 Álbumes)
ROLLING STONES IBC Demos 12 x 5 America Newest Hit Markers England's Newest Markers The Rolling Stones No.2 The Rolling Stones December's Children Out Of Our Heads The Rolling Stones, Now! Aftermath Big Hits Got Live If You Want Live Between The Buttons Flowers Their Satanic Majesties Request Beggars Banquet Let It Bleed Through The Past, Darkly Get Yer Ya-Ya's Out! Rarities Sticky Fingers Exile On Main Hot Rocks More Hot Rocks Unreleased Decca Live Album Welcome To New York Goat Head Soup It's Only Rock'n Roll Unplugged Made In The Shade Metamorphosis Love You Live Some Girls Emotional Rescue Sucking In The Seventies Tattoo You Still Life Undercover Rewind Dirty Work Steel Wheels The London Year Flaspoint Jump Back Voodoo Lounge Stripped The Rolling Stones rock and roll circus Bridges Of Babylon No Security Live Licks A Bigger Bang Slow Stones Shine a Light Exile On Main St Black And Blue Mick Jagger From Far East To Down under Through The Years Tokyo Shuffle Mick Jagger and the Red Devils We Want Moore Jagger She's The Boss Primitive Cool Rehearsals Primitive Cool Can't You Hear Me Rocking Stage Flight Wandering Spirit Goddess In The Doorway Alfie (Sound Track) Guest Of Honor Vol 1 Guest Of Honor Vol 2 Guest Of Honor Vol 3 Guest Of Honor Vol 4 Melbourne, 6 October, 1988 Nagoya, 25 March, 1988 State Of Shock One Night Stand Sencillos The Very Best Of Mick Jagger Webster Hall Livey
macppc: GPIO macobio(4) cleanup
On macppc there are many way to get the gpio addresses of the devices
through the openfirmware.
Depending of the model you can read that address directly (property
AAPL,address), read an offset (in reg) sometimes relative to the gpio
controllers address sometimes relative to the base address of the I/O
bus. And sometimes the address/offset is not even read but hardcoded in
the drivers.
The following diff is a first step to unify this and exposes 4 methods,
3 of which already existed, to manage gpios with an offset from the I/O
bus base address.
Index: dev/i2s.c
===
RCS file: /cvs/src/sys/arch/macppc/dev/i2s.c,v
retrieving revision 1.18
diff -u -p -r1.18 i2s.c
--- dev/i2s.c 15 Jul 2010 03:43:11 - 1.18
+++ dev/i2s.c 26 Apr 2011 12:15:37 -
@@ -46,6 +46,7 @@
#include macppc/dev/i2svar.h
#include macppc/dev/i2sreg.h
+#include macppc/pci/macobio.h
#ifdef I2S_DEBUG
# define DPRINTF(x) printf x
@@ -78,10 +79,6 @@ void i2s_init(struct i2s_softc *, int);
int i2s_intr(void *);
int i2s_iintr(void *);
-/* XXX */
-void keylargo_fcr_enable(int, u_int32_t);
-void keylargo_fcr_disable(int, u_int32_t);
-
struct cfdriver i2s_cd = {
NULL, i2s, DV_DULL
};
@@ -95,25 +92,6 @@ static int headphone_detect_active;
static u_char *lineout_detect;
static int lineout_detect_active;
-/* GPIO bits */
-#define GPIO_OUTSEL0xf0/* Output select */
- /* 0x00GPIO bit0 is output
- 0x10media-bay power
- 0x20reserved
- 0x30MPIC */
-
-#define GPIO_ALTOE 0x08/* Alternate output enable */
- /* 0x00Use DDR
- 0x08Use output select */
-
-#define GPIO_DDR 0x04/* Data direction */
-#define GPIO_DDR_OUTPUT0x04/* Output */
-#define GPIO_DDR_INPUT 0x00/* Input */
-
-#define GPIO_LEVEL 0x02/* Pin level (RO) */
-
-#defineGPIO_DATA 0x01/* Data */
-
void
i2s_attach(struct device *parent, struct i2s_softc *sc, struct confargs *ca)
{
@@ -951,7 +929,7 @@ i2s_set_rate(sc, rate)
/* Clear CLKSTOPPEND */
out32rb(sc-sc_reg + I2S_INT, I2S_INT_CLKSTOPPEND);
- keylargo_fcr_disable(I2SClockOffset, I2S0CLKEN);
+ macobio_disable(I2SClockOffset, I2S0CLKEN);
/* Wait until clock is stopped */
for (timo = 50; timo 0; timo--) {
@@ -967,7 +945,7 @@ done:
in32rb(sc-sc_reg + I2S_FORMAT), reg));
out32rb(sc-sc_reg + I2S_FORMAT, reg);
- keylargo_fcr_enable(I2SClockOffset, I2S0CLKEN);
+ macobio_enable(I2SClockOffset, I2S0CLKEN);
sc-sc_rate = rate;
Index: dev/xlights.c
===
RCS file: /cvs/src/sys/arch/macppc/dev/xlights.c,v
retrieving revision 1.4
diff -u -p -r1.4 xlights.c
--- dev/xlights.c 30 Sep 2008 04:54:00 - 1.4
+++ dev/xlights.c 26 Apr 2011 12:15:37 -
@@ -27,6 +27,7 @@
#include machine/autoconf.h
#include macppc/dev/dbdma.h
#include macppc/dev/i2sreg.h
+#include macppc/pci/macobio.h
struct xlights_softc {
struct device sc_dev;
@@ -55,8 +56,6 @@ void xlights_startdma(struct xlights_sof
void xlights_deferred(void *);
void xlights_theosDOT(void *);
void xlights_timeout(void *);
-extern void keylargo_fcr_enable(int, u_int32_t);
-extern void keylargo_fcr_disable(int, u_int32_t);
struct cfattach xlights_ca = {
sizeof(struct xlights_softc), xlights_match,
Index: pci/macobio.c
===
RCS file: /cvs/src/sys/arch/macppc/pci/macobio.c,v
retrieving revision 1.18
diff -u -p -r1.18 macobio.c
--- pci/macobio.c 22 Aug 2009 02:54:50 - 1.18
+++ pci/macobio.c 26 Apr 2011 12:15:37 -
@@ -45,6 +45,7 @@
#include machine/bus.h
#include machine/autoconf.h
+#include macppc/pci/macobio.h
void macobio_attach(struct device *, struct device *, void *);
int macobio_match(struct device *, void *, void *);
@@ -257,12 +258,8 @@ mac_intr_disestablish(void *lcp, void *a
(*mac_intr_disestablish_func)(lcp, arg);
}
-void keylargo_fcr_enable(int offset, u_int32_t bits);
-void keylargo_fcr_disable(int offset, u_int32_t bits);
-u_int32_t keylargo_fcr_read(int offset);
-
void
-keylargo_fcr_enable(int offset, u_int32_t bits)
+macobio_enable(int offset, u_int32_t bits)
{
struct macobio_softc *sc = macobio_cd.cd_devs[0];
if (sc-obiomem == 0)
@@ -272,7 +269,7 @@ keylargo_fcr_enable(int offset, u_int32_
out32rb(sc-obiomem + offset, bits);
}
void
-keylargo_fcr_disable(int offset, u_int32_t bits)
+macobio_disable(int offset, u_int32_t bits)
{
struct macobio_softc *sc = macobio_cd.cd_devs[0];
if (sc-obiomem == 0)
@@ -283,13 +280,23 @@ keylargo_fcr_disable(int offset, u_int32
}
u_int32_t
-keylargo_fcr_read(int offset)
macppc: support for Dynamic Frequency Switching
The following diff adds support for dfs. It requires my precedent patch
about GPIOs. I don't have a machine with a MPC7448 so it's only tested
with a MPC7447A.
I'm also interested in various device-tree dumps for further development.
If you can send me yours, contact me off list.
Comments ?
Index: dev/dfs.c
===
RCS file: dev/dfs.c
diff -N dev/dfs.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ dev/dfs.c 26 Apr 2011 12:13:22 -
@@ -0,0 +1,150 @@
+/* $OpenBSD$ */
+/*
+ * Copyright (c) 2011 Martin Pieuchot m...@nolizard.org
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include sys/param.h
+#include sys/filedesc.h
+#include sys/sysctl.h
+
+#include machine/cpu.h
+#include machine/autoconf.h
+#include macppc/pci/macobio.h
+
+#defineDFS2(1 22) /* Divide-by-Two */
+#defineDFS4(1 23) /* Divide-by-Four (MPC7448 Specific) */
+
+extern int perflevel;
+static int voltage;
+
+intdfs_match(struct device *, void *, void *);
+void dfs_attach(struct device *, struct device *, void *);
+void dfs_setperf(int);
+void dfs_scale_frequency(u_int);
+
+struct cfattach dfs_ca = {
+ sizeof(struct device), dfs_match, dfs_attach
+};
+
+struct cfdriver dfs_cd = {
+ NULL, dfs, DV_DULL
+};
+
+int
+dfs_match(struct device *parent, void *arg, void *aux)
+{
+ struct confargs *ca = aux;
+ uint16_t cpu;
+
+ if (strcmp(ca-ca_name, cpu-vcore-select) != 0)
+ return (0);
+
+ cpu = ppc_mfpvr() 16;
+ if (cpu == PPC_CPU_MPC7447A || cpu == PPC_CPU_MPC7448)
+ return (1);
+
+ return (0);
+}
+
+void
+dfs_attach(struct device *parent, struct device *self, void *aux)
+{
+ struct confargs *ca = aux;
+ uint32_t hid1;
+ uint16_t cpu;
+
+ voltage = ca-ca_reg[0];
+
+ hid1 = ppc_mfhid1();
+
+ if (hid1 DFS4) {
+ ppc_curfreq = ppc_maxfreq / 4;
+ perflevel = 25;
+ } else if (hid1 DFS2) {
+ ppc_curfreq = ppc_maxfreq / 2;
+ perflevel = 50;
+ }
+
+ cpu_setperf = dfs_setperf;
+
+ printf(: Dynamic Frequency Switching, speeds: );
+ printf(%d, %d, ppc_maxfreq, ppc_maxfreq / 2);
+
+ cpu = ppc_mfpvr() 16;
+ if (cpu == PPC_CPU_MPC7448)
+ printf(, %d MHz\n, ppc_maxfreq / 4);
+ else
+ printf( MHz\n);
+}
+
+void
+dfs_setperf(int perflevel)
+{
+ if (perflevel 50) {
+ if (ppc_curfreq != ppc_maxfreq) {
+ macobio_write(voltage, GPIO_DDR_OUTPUT | 1);
+ DELAY(1000);
+ dfs_scale_frequency(FREQ_FULL);
+ }
+ } else {
+ uint16_t cpu;
+
+ cpu = ppc_mfpvr() 16;
+ if (cpu == PPC_CPU_MPC7448 perflevel = 25) {
+ if (ppc_curfreq != ppc_maxfreq / 4) {
+ dfs_scale_frequency(FREQ_QUARTER);
+ macobio_write(voltage, GPIO_DDR_OUTPUT | 0);
+ DELAY(1000);
+ }
+ } else {
+ if (ppc_curfreq != ppc_maxfreq / 2) {
+ dfs_scale_frequency(FREQ_HALF);
+ macobio_write(voltage, GPIO_DDR_OUTPUT | 0);
+ DELAY(1000);
+ }
+ }
+ }
+}
+
+void
+dfs_scale_frequency(u_int freq_scale)
+{
+ uint32_t hid1;
+ int s;
+
+ s = splhigh();
+ hid1 = ppc_mfhid1();
+
+ hid1 = ~(DFS2 | DFS4);
+ switch (freq_scale) {
+ case FREQ_QUARTER:
+ hid1 |= DFS4;
+ ppc_curfreq = ppc_maxfreq / 4;
+ break;
+ case FREQ_HALF:
+ hid1 |= DFS2;
+ ppc_curfreq = ppc_maxfreq / 2;
+ break;
+ case FREQ_FULL: /* FALLTHROUGH */
+ default:
+ ppc_curfreq = ppc_maxfreq;
+ }
+
+ asm volatile (sync);
+ ppc_mthid1(hid1);
+ asm volatile (sync; isync);
+
+ splx(s);
+}
Index: conf/GENERIC
===
RCS file:
Re: apply(1) small cleanup
On Tue, Apr 26, 2011 at 09:13:08PM +0500, Mark Lumsden wrote:
Make a Private function private and other things. ok?
-mark
Index: apply.c
===
RCS file: /cvs/src/usr.bin/apply/apply.c,v
retrieving revision 1.24
diff -u -p -r1.24 apply.c
--- apply.c 27 Oct 2009 23:59:35 - 1.24
+++ apply.c 26 Apr 2011 09:40:48 -
@@ -44,8 +44,8 @@
#include string.h
#include unistd.h
-void usage(void);
-int mysystem(const char *);
+static voidusage(void);
+__dead voidusage(void);
+static int mysystem(const char *);
Does this really matter in a signle .c application?
int
main(int argc, char *argv[])
@@ -179,8 +179,7 @@ main(int argc, char *argv[])
/* Run the command. */
if (debug)
(void)printf(%s\n, c);
- else
- if (mysystem(c))
+ else if (mysystem(c))
rval = 1;
}
@@ -191,14 +190,14 @@ main(int argc, char *argv[])
}
/*
- * system --
+ * mysystem --
* Private version of system(3). Use the user's SHELL environment
* variable as the shell to execute.
*/
-int
+static int
mysystem(const char *command)
{
- static char *name, *shell;
+ static const char *name, *shell;
pid_t pid;
int pstat;
sigset_t mask, omask;
@@ -235,7 +234,7 @@ mysystem(const char *command)
return(pid == -1 ? -1 : pstat);
}
-void
+static void
+__dead void
usage(void)
{
(void)fprintf(stderr,
--patrick
malloc: speed vs randomization
Hi,
This diff implements a tradeoff to gain speed at the cost of reducing
the randomness of chunk allocation in malloc slightly.
The idea is only to randomize the first half of chunks in a page. The
second half of chunks will fill in the gaps in-order. The
effectiveness of the current randomization decreases already with the
number of free slots diminishing in a page.
In one test case, this diff reduced the runtime from 31s to 25s. I'm
not completely sure if the reduced randomness is acceptable. But if
not, I like to commit the alternative mentioned in the comment since
i will always be 0 in that case. That alone already gives me a
measurable performance gain.
-Otto
Index: malloc.c
===
RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v
retrieving revision 1.127
diff -u -p -r1.127 malloc.c
--- malloc.c16 Dec 2010 18:47:01 - 1.127
+++ malloc.c26 Apr 2011 13:24:17 -
@@ -1025,23 +1025,27 @@ malloc_bytes(struct dir_info *d, size_t
k++;
}
- /* advance a random # of positions */
- i = getrnibble() % bp-free;
- while (i 0) {
- u += u;
- k++;
- if (k = MALLOC_BITS) {
- lp++;
- u = 1;
- k = 0;
+ /* advance a random # of positions if we didn't fill much yet */
+ /* alternatively if (bp-free 1) { */
+ if (bp-free 1 (mopts.malloc_guard || bp-free bp-total / 2)) {
+ i = getrnibble() % bp-free;
+ while (i 0) {
+ u += u;
+ k++;
+ if (k = MALLOC_BITS) {
+ lp++;
+ u = 1;
+ k = 0;
+ if (lp - bp-bits (bp-total - 1) /
+ MALLOC_BITS) {
+ wrterror(chunk overflow, NULL);
+ errno = EFAULT;
+ return (NULL);
+ }
+ }
+ if (*lp u)
+ i--;
}
- if (lp - bp-bits (bp-total - 1) / MALLOC_BITS) {
- wrterror(chunk overflow, NULL);
- errno = EFAULT;
- return (NULL);
- }
- if (*lp u)
- i--;
}
*lp ^= u;
Re: malloc: speed vs randomization
On Tue, Apr 26, 2011 at 9:33 AM, Otto Moerbeek o...@drijf.net wrote: This diff implements a tradeoff to gain speed at the cost of reducing the randomness of chunk allocation in malloc slightly. The idea is only to randomize the first half of chunks in a page. The second half of chunks will fill in the gaps in-order. The effectiveness of the current randomization decreases already with the number of free slots diminishing in a page. In one test case, this diff reduced the runtime from 31s to 25s. I'm not completely sure if the reduced randomness is acceptable. But if Perhaps a quarter? We want to prevent adjacent consecutive allocations, which is still very likely at the half way point, but diminishes after that.
Re: resurect and fix bce(4)
Janne Johansson wrote: 2011/4/3 Claudio Jeker cje...@diehard.n-r-g.com bce(4) was turned off because of limitations in the DMA engine that allows the chip to access only 1G of memory. On systems with more then 1G of memory hilarity ensued. Now I rewrote the driver to use bcopy() to copy the mbufs into a savely allocated DMA memory buffer. So the chip will now work with any ammount of memory in the machine. It works for me so if you own a bce(4) please test. FWIW, my loaner laptop from the job works fine with this, giving me bce0 back. (I used to limit ram to 1G when I needed bce before, don't have to anymore. I don't care for the performance drop, its far above 0 now) I can confirm this works nicely on my Acer TravelMate 4020 series laptop which has a built-in bce(4). The laptop only has half a gig of RAM so this was never an issue. Thanks for re-enabling this driver! Regards, Tom
arp(8) create / delete arp entries on rdomain not 0
It seems like something like that is missing :)
As previously, it does not behave correctly when you run it with route
-T$rdomain exec
and do not specify arp -V$rdomain, but that should not be used that way.
Index: arp.c
===
RCS file: /cvs/src/usr.sbin/arp/arp.c,v
retrieving revision 1.50
diff -u -r1.50 arp.c
--- arp.c 11 Jan 2011 16:34:20 - 1.50
+++ arp.c 25 Apr 2011 23:28:00 -
@@ -242,6 +242,10 @@
s = socket(PF_ROUTE, SOCK_RAW, 0);
if (s 0)
err(1, socket);
+ if (rdomain != 0)
+ if (setsockopt(s, AF_ROUTE, ROUTE_TABLEFILTER,
+ rdomain, sizeof(rdomain)) 0)
+ err(1, setsockopt(ROUTE_TABLEFILTER));
}
struct sockaddr_in so_mask = { 8, 0, 0, { 0x } };
Re: malloc: speed vs randomization
On Tue, Apr 26, 2011 at 10:09:23AM -0400, Ted Unangst wrote: On Tue, Apr 26, 2011 at 9:33 AM, Otto Moerbeek o...@drijf.net wrote: This diff implements a tradeoff to gain speed at the cost of reducing the randomness of chunk allocation in malloc slightly. The idea is only to randomize the first half of chunks in a page. The second half of chunks will fill in the gaps in-order. The effectiveness of the current randomization decreases already with the number of free slots diminishing in a page. In one test case, this diff reduced the runtime from 31s to 25s. I'm not completely sure if the reduced randomness is acceptable. But if Perhaps a quarter? We want to prevent adjacent consecutive allocations, which is still very likely at the half way point, but diminishes after that. Yes, that might be better, though you some of the performance gain is lost because you are scanning a lot of bits: i free bits + all bits in between that are not free. If a chunk page is pretty full, that's a lot of bits before you find the i'th free chunk. Originally I though most of the time was lost getting the random bits, but now it seems the scanning of the bits is to blame. Unless I'm misinterpreting my data -Otto
Re: malloc: speed vs randomization
On Tue, Apr 26, 2011 at 03:09:57PM -0500, Amit Kulkarni wrote: This diff implements a tradeoff to gain speed at the cost of reducing the randomness of chunk allocation in malloc slightly. The idea is only to randomize the first half of chunks in a page. The second half of chunks will fill in the gaps in-order. The effectiveness of the current randomization decreases already with the number of free slots diminishing in a page. In one test case, this diff reduced the runtime from 31s to 25s. I'm not completely sure if the reduced randomness is acceptable. But if Perhaps a quarter? We want to prevent adjacent consecutive allocations, which is still very likely at the half way point, but diminishes after that. Yes, that might be better, though you some of the performance gain is lost because you are scanning a lot of bits: i free bits + all bits in between that are not free. If a chunk page is pretty full, that's a lot of bits before you find the i'th free chunk. Originally I though most of the time was lost getting the random bits, but now it seems the scanning of the bits is to blame. Unless I'm misinterpreting my data Hi Otto, Now that OpenBSD defaults to use bigmem it will suffer from small page size on certain platforms like amd64, sparc64. How, why? Note that bigmem is/was only relevant on amd64. What do you guys think if the page size is dynamically adjusted to the datasize of FFS1 i.e when I fire up disklabel it is by default 16Kb on FFS1 on amd64. And higher on FFS2 only systems? Or you could base it on RAM size detected on system. I don't know what's best, you guys know. What page size are you talking about? Page size in the sense of allocation unit for mmap(2) is closely tied to the machine's hardware. You just cannot change that. Malloc page size could be make bigger, but that has drawbacks: not as many out-of-bound accesses will be caught. If then you combine with your original/tedu@ suggestion of consecutive allocations nearing end of page, it would be best. Then, you have a bigger page size which packs in more allocations and also gives more room to randomize. Of course,there is the problem of guard pages where memory is wasted, if you have guard page size == normal page size. Guard page size could be current page size, which is 4096 on amd64. This would take care of almost all scenarios, including supporting old drives, current disks with massive cache, and upcoming world of SSDs. And the RAM sizes are exploding too, 8GB stick is becoming mainstream. OpenBSD runs on more machines than your newest toys. malloc(3) is designed to be a general purpose allocater useable from a vax to big 64-bit machines. That brings some drawbacks, yes, but that's the way it is. IMHO, increasing the page size will lead to bigger sustainable gains. I'm not convinced. -Otto Thanks, amit
Any dpt(4) users still around?
If there's anyone out there still using dpt(4), I'd appreciate a quick
test of the diff below. No functional changes, just switching over to
using iopools.
dpt(4)'s not enabled by default in any kernel configs, and it didn't
even compile on 64-bit systems when I first started looking at it, so
I'm not holding my breath... anyway, I plan to just commit later this
week if I don't hear anything.
Index: dpt.c
===
RCS file: /cvs/src/sys/dev/ic/dpt.c,v
retrieving revision 1.30
diff -u -p -r1.30 dpt.c
--- dpt.c 26 Apr 2011 18:31:16 - 1.30
+++ dpt.c 26 Apr 2011 19:27:24 -
@@ -83,6 +83,8 @@ struct cfdriver dpt_cd = {
NULL, dpt, DV_DULL
};
+void *dpt_ccb_alloc(void *);
+void dpt_ccb_free(void *, void *);
#ifndef offsetof
#define offsetof(type, member) ((size_t)(((type *)0)-member))
@@ -297,6 +299,9 @@ dpt_init(sc, intrstr)
SLIST_INIT(sc-sc_free_ccb);
i = dpt_create_ccbs(sc, sc-sc_ccbs, sc-sc_nccbs);
+ mtx_init(sc-sc_ccb_mtx, IPL_BIO);
+ scsi_iopool_init(sc-sc_iopool, sc, dpt_ccb_alloc, dpt_ccb_free);
+
if (i == 0) {
printf(%s: unable to create CCBs\n, sc-sc_dv.dv_xname);
return;
@@ -360,6 +365,7 @@ dpt_init(sc, intrstr)
link-adapter = sc-sc_adapter;
link-adapter_softc = sc;
link-openings = sc-sc_nccbs;
+ link-pool = sc-sc_iopool;
config_found(sc-sc_dv, link, scsiprint);
}
}
@@ -602,18 +608,16 @@ dpt_minphys(struct buf *bp, struct scsi_
* Put a CCB onto the freelist.
*/
void
-dpt_free_ccb(sc, ccb)
- struct dpt_softc *sc;
- struct dpt_ccb *ccb;
+dpt_ccb_free(void *xsc, void *xccb)
{
- int s;
+ struct dpt_softc *sc = xsc;
+ struct dpt_ccb *ccb = xccb;
- s = splbio();
ccb-ccb_flg = 0;
- if (SLIST_NEXT(ccb, ccb_chain) == NULL)
- wakeup(sc-sc_free_ccb);
- splx(s);
+ mtx_enter(sc-sc_ccb_mtx);
+ SLIST_INSERT_HEAD(sc-sc_free_ccb, ccb, ccb_chain);
+ mtx_leave(sc-sc_ccb_mtx);
}
/*
@@ -675,31 +679,20 @@ dpt_create_ccbs(sc, ccbstore, count)
* none are available right now and we are permitted to sleep, then wait
* until one becomes free, otherwise return an error.
*/
-struct dpt_ccb *
-dpt_alloc_ccb(sc, flg)
- struct dpt_softc *sc;
- int flg;
+void *
+dpt_ccb_alloc(void *xsc)
{
+ struct dpt_softc *sc = xsc;
struct dpt_ccb *ccb;
- int s;
-
- s = splbio();
- for (;;) {
- ccb = SLIST_FIRST(sc-sc_free_ccb);
- if (ccb) {
- SLIST_REMOVE_HEAD(sc-sc_free_ccb, ccb_chain);
- break;
- }
- if ((flg SCSI_NOSLEEP) != 0) {
- splx(s);
- return (NULL);
- }
- tsleep(sc-sc_free_ccb, PRIBIO, dptccb, 0);
+ mtx_enter(sc-sc_ccb_mtx);
+ ccb = SLIST_FIRST(sc-sc_free_ccb);
+ if (ccb != NULL) {
+ SLIST_REMOVE_HEAD(sc-sc_free_ccb, ccb_chain);
+ ccb-ccb_flg |= CCB_ALLOC;
}
+ mtx_leave(sc-sc_ccb_mtx);
- ccb-ccb_flg |= CCB_ALLOC;
- splx(s);
return (ccb);
}
@@ -781,8 +774,7 @@ dpt_done_ccb(sc, ccb)
xs-status = ccb-ccb_scsi_status;
}
- /* Free up the CCB and mark the command as done */
- dpt_free_ccb(sc, ccb);
+ /* Mark the command as done */
scsi_done(xs);
}
@@ -808,34 +800,22 @@ dpt_scsi_cmd(struct scsi_xfer *xs)
SC_DEBUG(sc_link, SDEV_DB2, (dpt_scsi_cmd\n));
- /* Protect the queue */
- s = splbio();
-
/* Cmds must be no more than 12 bytes for us */
if (xs-cmdlen 12) {
xs-error = XS_DRIVER_STUFFUP;
scsi_done(xs);
- splx(s);
return;
}
- /* XXX we can't reset devices just yet */
- if ((xs-flags SCSI_RESET) != 0) {
- xs-error = XS_DRIVER_STUFFUP;
- scsi_done(xs);
- splx(s);
- return;
- }
-
- /* Get a CCB */
- if ((ccb = dpt_alloc_ccb(sc, xs-flags)) == NULL) {
- xs-error = XS_NO_CCB;
+ /* XXX we can't reset devices just yet */
+ if ((xs-flags SCSI_RESET) != 0) {
+ xs-error = XS_DRIVER_STUFFUP;
scsi_done(xs);
- splx(s);
return;
}
- splx(s);
+ ccb = xs-io;
+ ccb-ccb_flg = ~CCB_ALLOC;
ccb-ccb_xs = xs;
ccb-ccb_timeout = xs-timeout;
@@ -878,7 +858,6 @@ dpt_scsi_cmd(struct scsi_xfer *xs)
printf(error %d loading dma map\n, error);
xs-error = XS_DRIVER_STUFFUP;
-
Re: malloc: speed vs randomization
This diff implements a tradeoff to gain speed at the cost of reducing the randomness of chunk allocation in malloc slightly. The idea is only to randomize the first half of chunks in a page. The second half of chunks will fill in the gaps in-order. The effectiveness of the current randomization decreases already with the number of free slots diminishing in a page. In one test case, this diff reduced the runtime from 31s to 25s. I'm not completely sure if the reduced randomness is acceptable. But if Perhaps a quarter? We want to prevent adjacent consecutive allocations, which is still very likely at the half way point, but diminishes after that. Yes, that might be better, though you some of the performance gain is lost because you are scanning a lot of bits: i free bits + all bits in between that are not free. If a chunk page is pretty full, that's a lot of bits before you find the i'th free chunk. Originally I though most of the time was lost getting the random bits, but now it seems the scanning of the bits is to blame. Unless I'm misinterpreting my data Hi Otto, Now that OpenBSD defaults to use bigmem it will suffer from small page size on certain platforms like amd64, sparc64. What do you guys think if the page size is dynamically adjusted to the datasize of FFS1 i.e when I fire up disklabel it is by default 16Kb on FFS1 on amd64. And higher on FFS2 only systems? Or you could base it on RAM size detected on system. I don't know what's best, you guys know. If then you combine with your original/tedu@ suggestion of consecutive allocations nearing end of page, it would be best. Then, you have a bigger page size which packs in more allocations and also gives more room to randomize. Of course,there is the problem of guard pages where memory is wasted, if you have guard page size == normal page size. Guard page size could be current page size, which is 4096 on amd64. This would take care of almost all scenarios, including supporting old drives, current disks with massive cache, and upcoming world of SSDs. And the RAM sizes are exploding too, 8GB stick is becoming mainstream. IMHO, increasing the page size will lead to bigger sustainable gains. Thanks, amit
Re: apply(1) small cleanup
On 04/26/11 18:13, Mark Lumsden wrote: @@ -179,8 +179,7 @@ main(int argc, char *argv[]) /* Run the command. */ if (debug) (void)printf(%s\n, c); - else - if (mysystem(c)) + else if (mysystem(c)) rval = 1; FWIW, one tab too many after the fix. /Alexander
Re: Compiling the kernel with pcc
Hi, clang still can't compile the kernel on amd64 and presumably all other architectures. And I had sent a email to that effect to clang list. I had a env CC=clang make clean make depend make in my build_kernel.sh file it only works when you have env CC=clang make The recent removal of make depend exposed me. I removed clean depend as I do a rm -rf of the compile/GENERIC.MP folder Sorry about that, amit On Mon, 4 Apr 2011, Philip Guenther wrote: On Mon, Apr 4, 2011 at 11:06 AM, Pascal Stumpf pascal.stu...@cubes.de wrote: pcc currently only chokes on some inline functions that need external linkage. gcc isn't pesky about that, but pcc and clang are (rightfully, imo). It's completely legal and defined (by the standard and not just gcc!) for a function to be inline in the file where it's defined and have external linkage. That just means inline if you can in this file, but still provide a copy callable from other files. That's exactly the semantic we want for pf_addr_compare(). If pcc or clang are complaining about it they're broken or their warning settings are misset. Philip Guenther
spurious sys/types.h include in man pages
Maybe I am missing something but the following manpages don't really need sys/types.h. I compiled some small programs without sys/types.h. thanks, amit Index: mincore.2 === RCS file: /cvs/src/lib/libc/sys/mincore.2,v retrieving revision 1.10 diff -u mincore.2 --- mincore.2 31 May 2007 19:19:33 - 1.10 +++ mincore.2 27 Apr 2011 03:22:38 - @@ -37,7 +37,6 @@ .Nm mincore .Nd determine residency of memory pages .Sh SYNOPSIS -.Fd #include sys/types.h .Fd #include sys/mman.h .Ft int .Fn mincore void *addr size_t len char *vec Index: minherit.2 === RCS file: /cvs/src/lib/libc/sys/minherit.2,v retrieving revision 1.13 diff -u minherit.2 --- minherit.2 31 May 2007 19:19:33 - 1.13 +++ minherit.2 27 Apr 2011 03:22:38 - @@ -36,7 +36,6 @@ .Nm minherit .Nd control the inheritance of pages .Sh SYNOPSIS -.Fd #include sys/types.h .Fd #include sys/mman.h .Ft int .Fn minherit void *addr size_t len int inherit Index: mlock.2 === RCS file: /cvs/src/lib/libc/sys/mlock.2,v retrieving revision 1.16 diff -u mlock.2 --- mlock.2 31 May 2007 19:19:33 - 1.16 +++ mlock.2 27 Apr 2011 03:22:38 - @@ -38,7 +38,6 @@ .Nm munlock .Nd lock (unlock) physical pages in memory .Sh SYNOPSIS -.Fd #include sys/types.h .Fd #include sys/mman.h .Ft int .Fn mlock void *addr size_t len Index: mlockall.2 === RCS file: /cvs/src/lib/libc/sys/mlockall.2,v retrieving revision 1.5 diff -u mlockall.2 --- mlockall.2 26 Jun 2008 05:42:05 - 1.5 +++ mlockall.2 27 Apr 2011 03:22:38 - @@ -37,7 +37,6 @@ .Nm munlockall .Nd lock (unlock) the address space of a process .Sh SYNOPSIS -.Fd #include sys/types.h .Fd #include sys/mman.h .Ft int .Fn mlockall int flags Index: mmap.2 === RCS file: /cvs/src/lib/libc/sys/mmap.2,v retrieving revision 1.38 diff -u mmap.2 --- mmap.2 11 Apr 2011 17:46:19 - 1.38 +++ mmap.2 27 Apr 2011 03:22:38 - @@ -37,7 +37,6 @@ .Nm mmap .Nd map files or devices into memory .Sh SYNOPSIS -.Fd #include sys/types.h .Fd #include sys/mman.h .Ft void * .Fn mmap void *addr size_t len int prot int flags int fd off_t offset Index: mprotect.2 === RCS file: /cvs/src/lib/libc/sys/mprotect.2,v retrieving revision 1.15 diff -u mprotect.2 --- mprotect.2 12 Feb 2010 21:49:10 - 1.15 +++ mprotect.2 27 Apr 2011 03:22:38 - @@ -37,7 +37,6 @@ .Nm mprotect .Nd control the protection of pages .Sh SYNOPSIS -.Fd #include sys/types.h .Fd #include sys/mman.h .Ft int .Fn mprotect void *addr size_t len int prot Index: msync.2 === RCS file: /cvs/src/lib/libc/sys/msync.2,v retrieving revision 1.21 diff -u msync.2 --- msync.2 31 May 2007 19:19:33 - 1.21 +++ msync.2 27 Apr 2011 03:22:38 - @@ -37,7 +37,6 @@ .Nm msync .Nd synchronize a mapped region .Sh SYNOPSIS -.Fd #include sys/types.h .Fd #include sys/mman.h .Ft int .Fn msync void *addr size_t len int flags Index: munmap.2 === RCS file: /cvs/src/lib/libc/sys/munmap.2,v retrieving revision 1.14 diff -u munmap.2 --- munmap.231 Jan 2009 16:52:15 - 1.14 +++ munmap.227 Apr 2011 03:22:38 - @@ -37,7 +37,6 @@ .Nm munmap .Nd remove a mapping .Sh SYNOPSIS -.Fd #include sys/types.h .Fd #include sys/mman.h .Ft int .Fn munmap void *addr size_t len Index: ptrace.2 === RCS file: /cvs/src/lib/libc/sys/ptrace.2,v retrieving revision 1.26 diff -u ptrace.2 --- ptrace.216 Sep 2008 19:41:06 - 1.26 +++ ptrace.227 Apr 2011 03:22:38 - @@ -9,7 +9,6 @@ .Nm ptrace .Nd process tracing and debugging .Sh SYNOPSIS -.Fd #include sys/types.h .Fd #include sys/ptrace.h .Ft int .Fn ptrace int request pid_t pid caddr_t addr int data Index: shmat.2 === RCS file: /cvs/src/lib/libc/sys/shmat.2,v retrieving revision 1.14 diff -u shmat.2 --- shmat.2 31 May 2007 19:19:33 - 1.14 +++ shmat.2 27 Apr 2011 03:22:38 - @@ -38,7 +38,6 @@ .Nm shmdt .Nd map/unmap shared memory .Sh SYNOPSIS -.Fd #include sys/types.h .Fd #include sys/ipc.h .Fd #include sys/shm.h .Ft void * Index: shmctl.2 === RCS file: /cvs/src/lib/libc/sys/shmctl.2,v retrieving revision 1.13 diff -u shmctl.2 --- shmctl.231 May 2007 19:19:33 - 1.13 +++ shmctl.227 Apr 2011 03:22:38 - @@ -37,7 +37,6 @@ .Nm shmctl .Nd shared memory control operations .Sh
Re: apply(1) small cleanup
On Tue, Apr 26, 2011 at 05:59:45AM -0700, patrick keshishian wrote: On Tue, Apr 26, 2011 at 09:13:08PM +0500, Mark Lumsden wrote: Make a Private function private and other things. ok? -mark Index: apply.c === RCS file: /cvs/src/usr.bin/apply/apply.c,v retrieving revision 1.24 diff -u -p -r1.24 apply.c --- apply.c 27 Oct 2009 23:59:35 - 1.24 +++ apply.c 26 Apr 2011 09:40:48 - @@ -44,8 +44,8 @@ #include string.h #include unistd.h -void usage(void); -intmysystem(const char *); +static voidusage(void); +__dead void usage(void); is __dead portable across all compilers/archs? -mark PS I see it sprinkled through the src tree though.
Re: spurious sys/types.h include in man pages
Maybe I am missing something but the following manpages don't really need sys/types.h. you are wrong. You are only trying on OpenBSD. If only everything was OpenBSD. However, everything is not OpenBSD.
