headers
Ivan Voras | 18 May 2013 06:04
Picon
Favicon
Gravatar

blogbench and write-open serialization

During the BSDCan & DevSummit I got interested in finding out why
blogbench is so slow on FreeBSD. After talking to jhb, it looked like
one of the reasons might be that opening files with O_RDWR or O_WRONLY
(anything opening the file for writing) is serialized.

To check this, I've written a small test program, which I've run on
CentOS 6.3 and FreeBSD 10-HEAD on the same hardware. Here are the results:

https://wiki.freebsd.org/Benchmarking/OpenCloseBenchmark

Conclusions:

* Linux opens and closes files much faster than FreeBSD
* Linux does not serialize write-open operations, while FreeBSD does
* Even with O_RDONLY, FreeBSD is much slower in opening (and closing) files.

I'd welcome a review of these results and comments.

_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply | 1 comment |
headers
Zaphod Beeblebrox | 16 May 2013 22:51
Picon

tape (sa0) on sparc64 ?

I have to retrieve some very old backups.  They were made on FreeBSD and
are on tape... specifically DDS4.  I have a DDS4 drive and I ordered cables
that hook it up to my sparc64.  For fun and giggles I have both the
motherboard controller...

sym0: <1010-66> port 0x900-0x9ff mem 0x100000-0x1003ff,0x102000-0x103fff at
device 2.0 on pci2
sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking
sym1: <1010-66> port 0xa00-0xaff mem 0x104000-0x1043ff,0x106000-0x107fff at
device 2.1 on pci2
sym1: No NVRAM, ID 7, Fast-80, LVD, parity checking

and an adaptec controller

ahc0: <Adaptec 3960D Ultra160 SCSI adapter> port 0x300-0x3ff mem
0x100000-0x100fff at device 1.0 on pci3
aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
ahc1: <Adaptec 3960D Ultra160 SCSI adapter> port 0x400-0x4ff mem
0x102000-0x102fff at device 1.1 on pci3
aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs

in the box.

The tape drive is terminated with an external terminator (which seems
proper since I found it in my collection with that terminator still
attached).  I have tried the tape connected to both the internal and
adaptec controllers.  Right now it shows up as:

sa0 at sym1 bus 0 scbus3 target 2 lun 0
sa0: <HP C5683A C908> Removable Sequential Access SCSI-2 device
(Continue reading)

Permalink | Reply | 9 comments |
headers
Daniel Eischen | 16 May 2013 00:48
Picon
Favicon

Logging natd translations

We need to log all translations from internal IP addresses to
external addresses.  It's good enough to have IPv4 to Ipv4
translations for TCP streams, just one log for the start of
each stream.

We're using FreeBSD-9.1-stable and IPFW with userland natd.
The -log option of natd just seems to log statistics, not
any translation information.  I can't see any easy way to
do this with ipfw's rule log option either.

Any ideas?

--

-- 
DE
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply | 3 comments |
headers
Mike Ma | 14 May 2013 10:00
Picon

How to get ucred/xucred in user space?

Hi folks,

Can I ask if there's any way to get ucred/xucred of a process in user space?
As I'm trying to port glustertfs and it's a userland filesystem, I need to
get secondary groups of a process.

AFAIK, Linux gets them in /proc and NetBSD gets them in this way:
        int name[] = { CTL_KERN, KERN_PROC, KERN_PROC_PID, frame->root->pid
};
        size_t namelen = sizeof name / sizeof name[0];
        struct kinfo_proc kp;
        size_t kplen = sizeof(kp);
int i, ngroups;
        if (sysctl(name, namelen, &kp, &kplen, NULL, 0) != 0)
                return;
        ngroups = MIN(kp.kp_eproc.e_ucred.cr_ngroups, GF_REQUEST_MAXGROUPS);

I realized none of them would work in FreeBSD.
I'm wondering if there's any alternative way to get group information?

--

-- 
Cheers,
Mike
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply | 1 comment |
headers
Eugen-Andrei Gavriloaie | 13 May 2013 17:19
Picon

Managing userland data pointers in kqueue/kevent

Hello to all,

I'm trying to reply to this thread:
http://lists.freebsd.org/pipermail/freebsd-hackers/2010-November/033565.html

I also faced this very difficult task of tracking down the user data registered into kq.
I end up having some "Tokens" instances which I never deallocate but always re-use them or create new ones if
necessary. This tokens are used as user data for kq. They are keeping the actual pointers inside them, and
the pointer itself has a reference to the Token. When the pointer dies, I reset the guts of the token. When
the time comes to use the token, I have the guarantee is not the corpse of a token (never deallocate them,
remember?) and I can see that the actual pointer was gone, everyone is happy. At the application shutdown,
I cleanup the mess (the tokens). However, I just want to say that Paul has a valid point when he is wondering
why EV_FREEWATCH was not provisioned/implemented. 

The moment we throw multi-threading into equation, this becomes a extremely hard thing to manage (close to
impossible), including my "proven-to-work" Token trick.  It renders the user data pointer completely
useless because in the end we need to keep an association map inside user space. That is forcing user space
code to do a lookup before use, instead of straightforward use. Not to mention the fact that we need to
perform a lock before searching it. That brings havoc on kernel side on 1000+ active connections (a
multi-threaded streaming server for example). 

I'm pretty sure this user data pointer is also breaking a well known pointer management paradigm, but I just
can't remember which. Regardless, it has all the ingredients for memory leaks and/or, the worst one, use
of corpse pointers which are bound to crash the app. I agree, C/C++ is not for the faint of heart, but with
little or close to no efforts, his EV_FREEWATCH can be put to very good use, and user space code not only
becomes less prone to mem issues, but also cleaner.

To summarise, +1 for the EV_FREEWATCH. I simply love the idea! Clean and very very efficient.

Best regards,
(Continue reading)

Permalink | Reply | 18 comments |
headers
Computer Network Man | 13 May 2013 08:37
Picon

A problem with alq module!

Dear Guys;
In a fresh FreeBSD 9 or 9.1 Release if you just run these commands:
# kldload alq
# kldunload alq
# init 0 or shutdown -p now
it will panic!
maybe it's a bug.
We have a module which uses alq API's.
    MODULE_DEPEND(mymodule, alq, 1, 1, 1)
when our module starts, loads alq. and when it stops, unloads alq. So after
starting and stoping our module and shutdown, we have panic.
any opinion in this regard would be appreciated.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply | 2 comments |
headers
Gabor Pali | 12 May 2013 19:54
Picon
Favicon
Gravatar

FreeBSD Quarterly Status Report, January-March 2013

FreeBSD Quarterly Status Report, January-March 2013

Introduction

   This report covers FreeBSD-related projects between January and March
   2013. This is the first of four reports planned for 2013.

   Highlights from this status report include the busy preparations of
   8.4-RELEASE, restoration of binary package building, steady progress of
   several porting efforts, like work on the FreeBSD ports of xorg, GNOME,
   KDE, and Xfce, bringing FreeBSD to Cubieboard and Hackberry boards,
   development of ARM and AMD GPU support, improving performance of
   UFS/FFS and callouts, and introducing a multipath TCP implementation
   for the network stack.

   Thanks to all the reporters for the excellent work! This report
   contains 31 entries and we hope you enjoy reading it.

   The deadline for submissions covering the period between April and June
   2013 is July 7th, 2013.
     __________________________________________________________________

Projects

     * FreeNAS
     * Kernel Information in Process Core Dumps
     * Native iSCSI Stack

FreeBSD Team Reports
(Continue reading)

Permalink | Reply | 5 comments |
headers
Vijay Singh | 11 May 2013 00:01
Picon

anyone running the ofed code

Apologies for the cross post. Were trying out the ofed code and running
into some issues, so would love to discuss.

-vijay
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
Karl Dreger | 10 May 2013 21:31
Picon
Favicon

syscall to userland interface

Hello,
I have been taking a look at a few syscalls in /usr/src/sys/kern/ and
always find that in their actuall c definition the function names are
preprended by a sys_. Take for example the fork system call which
is found in /usr/src/sys/kern/kern_fork.c

int
sys_fork(struct thread *td, struct fork_args *uap)
...

Now when I write a program from userland, that makes use of the 
fork system call, then if call it as:

fork();

All the syscall are part of libc, which is usually defined in 
/usr/src/lib/libc/

Since the system calls are already defined in the kernel sources, they 
no longer need to be defined in /usr/src/lib/libc/. This is the reason 
why one can only find the manpages and no c files in 
/usr/src/lib/libc/sys?
At least this is how my thinking goes.

Now, when the syscalls in the kernel sources are all defined as sys_xxx 
but are invoked as xxx and the c headers also show syscall prototypes 
without any prepended sys. How does the actual user-, kernelland 
move happen? In other words, why do I invoke fork() as fork() and
not as sys_fork()?
(Continue reading)

Permalink | Reply | 6 comments |
headers
Alexander Leidinger | 9 May 2013 11:07
Favicon

priv_check/make_dev/devfs.rules: What is preventing a device to show up in a jail?

Hi,

big picture: I want to get access to my USB DVB device in a jail. First
I explain what works (to show what I already know in this regard), then
I explain what doesn't work (where I seem to lack some knowledge).

What I did so far:
I already patched my kernel to give access to /dev/io and /dev/dri in a
jail to have X1 up and running in a jail (works since some years):
 - changed PRIV_DRIVER to PRIV_DRI_DRIVER (new in my kernel)
   for the priv_check() for /dev/dri
 - added cases PRIV_IO and PRIV_DRI_DRIVER to sys/kern/kern_jail.c
   which allow access if a specific allow.xxx flag is set for the jail
 - added the following lines to devfs.rules in a x11-jail specific
   section (plus some more devices):
---snip---
add path agpgart unhide
add path dri unhide
add path 'dri*' unhide
add path nvidiactl unhide
add path 'nvidia*' unhide
add path io unhide
add path mem unhide
---snip---

Patches at http://www.Leidinger.net/FreeBSD/current-patches/0_jail.diff

Result so far:
 - I see the io/mem/nvidia* devices (when I had a Radeon card which
   used /dev/dri, I was also seeing the devices in the /dev/dri/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Teske, Devin | 7 May 2013 21:04

[UPDATE] sysutils/bsdconfig snapshot

Hi fellow -hackers <at> ,

I've taken a new snapshot of HEAD usr.sbin/bsdconfig and made it available through the ports tree. The last
snapshot was almost 12 full months ago, and a lot has changed since then.

Most notably, we have the beginnings of the package management module now and we're edging ever-closer to
1.0 release status.

I'd like to see if there are any interested folks out there that could give my updated sysutils/bsdconfig
port a go and provide some feedback (while I'm still in lighter development phase).

Any/all feedback would be greatly appreciated.

Just an FYI however… this code is only expected to work on 9.0-R or higher.
--

-- 
Cheers,
Devin

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended
recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the
message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons other than the intended
recipient. Thank you.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
(Continue reading)

Permalink | Reply | 0 comments |

Gmane