Re: [perf-discuss] segmap_kpm on x86

Dale Ghent wrote: On May 14, 2009, at 10:24 PM, prakash sangappa wrote: However, a new set of interfaces called VPM was introduced which provide transient mappings to file pages similar, to segmap. The VPM interfaces use KPM mappings. The UFS, NFS, TMPFS and SPECfs filesystem use the VPM

Re: [perf-discuss] segmap_kpm on x86

Dale Ghent wrote: I'm observing the segmap_kpm variable on a running 64bit kernel and it's value is 0. It seems to be explicitly set as such at: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/i86pc/os/startup.c#1969 The segmap segment cannot use KPM mappings on x64 syste

Re: [perf-discuss] Benchmarking NFS using tmpfs Shares

Ben Rockwood wrote: > I was doing some NFS benchmarking over the weekend with undesirable > results. I thought that I'd use a share from tmpfs in order to contrast > my results. I expected line speed NFS performance... but the results > were horrible, far slower than any disk-based NFS benchmark.

Re: [perf-discuss] question about port_associate()

Sophie Hu wrote: > I know that each time after port_getn() returns some events, the related > sockets have to be re-associated after the events are processed(read, write, > accept…). But since in my code, there are many places where events are > processed (read), in order not to miss any socket

Re: [perf-discuss] can anybody explain the difference between select() and port_getn()

Sophie Hu wrote: > It seems that all of you are expert at port and select(). Let me ask another > question: Actually I found sth. strange when I use port_get(). I am not sure > if it is a bug of port_getn() or if it is due to my code. just FYI in case > you used to have the same problem or you a

Re: [perf-discuss] Poor swap performance

That is an internal link to the bug report. Here is the external link http://bugs.opensolaris.org/view_bug.do?bug_id=6583268 -Prakash. Prakash Sangappa wrote: > Are you running Solaris 10u3+? In that case this problem may be due > to > > 6583268 tmpfs tries too hard to reserve mem

Re: [perf-discuss] Poor swap performance

Are you running Solaris 10u3+? In that case this problem may be due to 6583268 tmpfs tries too hard to reserve memory . This is currently fixed in Nevada. I guess it will be back ported to S10 patch. -Prakash. * * adrian cockcroft wrote: > How fast do

Re: [perf-discuss] Re: kaio problem, whether solaris kaio support socket?

Hi, Yes, unfortunately kernel async I/O(AIO) is not supported on sockets. If the AIO requests on sockets, it will be handled by libaio which simulates it using worker threads. If you have blocking I/O (reads) being performed on all these sockets, then the libaio implementation could end up

Re: [perf-discuss] Problem with SIGEV_THREAD and POSIX message queues

Got a chance to investigate the test case. For each notification request registered, only one notification will be sent. Once a notification is sent to the process, the registration is removed. The process has to re-register the notification again to receive the next notification. This is document

Re: [perf-discuss] Problem with SIGEV_THREAD and POSIX message queues

Ignore my previous reply. The explanation is not correct. I need to investigate the test case and get back. -Prakash. prakash sangappa wrote: Hi Micheal, Yes, there is a problem here. Looking at the code and your test output, we can see that there is a race condition between

Re: [perf-discuss] Problem with SIGEV_THREAD and POSIX message queues

Hi Micheal, Yes, there is a problem here. Looking at the code and your test output, we can see that there is a race condition between __mq_timedsend() and __mq_timedreceive(). Note that __mq_timedrecieve() does not hold the mq_exclusive mutex when calling the sem_trywait(&mqhp->mq_notempty)

Re: [perf-discuss] Read lock contention, solaris 9, 32 cores host.

The default value of 1000 has been experimentally determined. This count is the number of times adaptive mutex lock will spin attempting, to get the lock, before it blocks in the kernel. Note, that it spins only if the owner of the lock is running. Increasing the number would mean that if the

Re: [perf-discuss] Re: File events notification mechansim

Gamin/FAM is different from libevent. Gamin/FAM provides file monitoring services where as 'libevent' provides a general event notification API to collect events from different sources. Libevent interfaces with the event notification framework that the OS provides. The the event notificat

Re: [perf-discuss] Read lock contention, solaris 9, 32 cores host.

From the pstack info, the thread is blocking often in the kernel. It is possible that the treads are blocking more often in the kernel on this Ultra IV system running Solaris 9. One thing you can try is increase the adaptive spin count for the mutex locks and see if it helps. The default cou

Re: [perf-discuss] Read lock contention, solaris 9, 32 cores host.

Yes the implementation is different between the Sol9 and Sol10. It is possible that the Solaris 10 implementation spins on the mutex lock and is able to get it quickly. Can you share the pstack output collected on Solaris 9 when the threads are contending on the mutex lock? -Prakash. Konstantin

Re: [perf-discuss] File event API

Joe Shaw wrote: Hi, On Thu, 2006-11-16 at 16:03 -0800, Prakash Sangappa wrote: How is file creation handled? It seems like you would need an event analogous to FILE_DELETE here to notice any newly added files. The file creation will result in a FILE_MODIFIED event on the

Re: [perf-discuss] File event API

Joe Shaw wrote: Hi Prakash, Thanks for your reply! On Thu, 2006-11-16 at 12:15 -0800, Prakash Sangappa wrote: As it has been previously discussed, watching for file events on an entire filesystem or a directory tree can be a scalability issue. So the File events API may not be suitable

Re: [perf-discuss] File event API

Hi Joe, As it has been previously discussed, watching for file events on an entire filesystem or a directory tree can be a scalability issue. So the File events API may not be suitable for an application like the desktop search. For a desktop search system like Beagle or spotlight, it appears

Re: [perf-discuss] lock contention in ioctl() and scalability issues

The 'uf_lock' is a per 'fd' lock. Therefore, the application could possibly dup(2) the fd, to get one for each thread. That should help avoid the uf_lock contention. -Prakash. Krishna Yenduri wrote: Bart Smaalders wrote: Krishna Yenduri wrote: ... This lock is uf_lock of the device file

Re: [perf-discuss] File events notification mechansim

[snip] We have a good discussion going. To summarize... File event types FILE_ACCESS File was accessed FILE_MODIFIED File was modified. FILE_CREATE File/directory was created. FILE_DELETE File/directory was deleted. FILE_ATTRIB Fil

Re: [perf-discuss] File events notification mechansim

n Levon wrote: On Wed, May 03, 2006 at 07:31:08PM -0700, Prakash Sangappa wrote: If you where to watch for events on an entire directory tree, what types of events that would be? Presumably there would be some way to specify, but file creation/deletion would be the most obvi

Re: [perf-discuss] File events notification mechansim

Spencer Shepler wrote: It appears that the distributed filesystem implementation should provide necessary means to collect such events. I think the responsibility falls squarely on the distributed file system implementation. I don't of if there are any distributed file system implementation

Re: [perf-discuss] File events notification mechansim

re are any distributed file system implementation which can do that. -Prakash. Thanks, Darren. Prakash Sangappa wrote: Glynn Foster wrote: Yeah, currently Beagle only indexes a relatively small amount of per-user data, generally in $HOME - however, as has been mentioned, it's probably

Re: [perf-discuss] File events notification mechansim

Glynn Foster wrote: Yeah, currently Beagle only indexes a relatively small amount of per-user data, generally in $HOME - however, as has been mentioned, it's probably one of the first proper use cases of inotify. I'd suggest that it's definitely worth looking at what inotify does - given th

Re: [perf-discuss] File events notification mechansim

John Levon wrote: On Thu, May 04, 2006 at 08:46:01AM -0700, Bart Smaalders wrote: Does this mean we don't get told /what/ got created? Is an application that wants to know "what files are disappearing/appearing under /foo/bar/?" going to have to readdir() the whole directory every time it get

Re: [perf-discuss] File events notification mechansim

John Levon wrote: On Wed, May 03, 2006 at 02:44:01PM -0700, Prakash Sangappa wrote: FILE_CREATE File/Directory was created. I think GNOME and others want to be able to watch an entire directory tree. It sounds like the proposal is that you can only watch a particular

[perf-discuss] File events notification mechansim

Hi All, We are working on adding a 'file events notification/monitoring' mechanism to the Event ports framework in Solaris. There are several different implementations around this file events notification mechanism currently available, like 'dnotify, inotify' for Linux or the 'FAM' from SGI e

Re: [perf-discuss] Kernel Asynchronous I/O

cated. Since there is no kernel async I/O support for UFS, I don't think we could compare async I/O performance on UFS between userland version and kernel. Unless some one has hacked the code and tried it. -Prakash. Prakash Sangappa wrote: That is because the filesystem framework (VFS/

Re: [perf-discuss] Kernel Asynchronous I/O

That is because the filesystem framework (VFS/VNODE) and the filesystems do not implement an async I/O interface. This requires that the relevant modules (filesystems) implement the necessary I/O queuing and notification mechanism for async I/O requests. The kernel async I/O is currently imple