On Thu, Mar 07, 2013 at 08:54:55AM -0700, Dave Kleikamp wrote:
> On 03/07/2013 06:55 AM, Chris Mason wrote:
> > On Thu, Mar 07, 2013 at 01:45:33AM -0700, Peter Zijlstra wrote:
> >> On Tue, 2013-03-05 at 15:53 -0500, Rik van Riel wrote:
> >>
> >>> Indeed. Though how well my patches will work with O
On 03/07/2013 06:55 AM, Chris Mason wrote:
> On Thu, Mar 07, 2013 at 01:45:33AM -0700, Peter Zijlstra wrote:
>> On Tue, 2013-03-05 at 15:53 -0500, Rik van Riel wrote:
>>
>>> Indeed. Though how well my patches will work with Oracle will
>>> depend a lot on what kind of semctl syscalls they are doin
On Thu, Mar 07, 2013 at 01:45:33AM -0700, Peter Zijlstra wrote:
> On Tue, 2013-03-05 at 15:53 -0500, Rik van Riel wrote:
>
> > Indeed. Though how well my patches will work with Oracle will
> > depend a lot on what kind of semctl syscalls they are doing.
> >
> > Does Oracle typically do one semop
On Tue, 2013-03-05 at 15:53 -0500, Rik van Riel wrote:
> Indeed. Though how well my patches will work with Oracle will
> depend a lot on what kind of semctl syscalls they are doing.
>
> Does Oracle typically do one semop per semctl syscall, or does
> it pass in a whole bunch at once?
https://os
On Tue, Mar 5, 2013 at 11:13 PM, Davidlohr Bueso wrote:
>
> Digging into the _raw_spin_lock call:
>
> 17.86% oracle [kernel.kallsyms] [k] _raw_spin_lock
> |
> --- _raw_spin_lock
> |
> |--49.55%-
On Tue, 2013-03-05 at 22:53 -0500, Rik van Riel wrote:
> On 03/05/2013 10:46 PM, Waiman Long wrote:
> > On 03/05/2013 03:53 PM, Rik van Riel wrote:
>
> >> Indeed. Though how well my patches will work with Oracle will
> >> depend a lot on what kind of semctl syscalls they are doing.
> >>
> >> Does
On Tue, 2013-03-05 at 07:40 -0800, Linus Torvalds wrote:
> On Tue, Mar 5, 2013 at 1:35 AM, Davidlohr Bueso
> wrote:
> >
> > The following set of patches are based on the discussion of holding the
> > ipc lock unnecessarily, such as for permissions and security checks:
>
> Ok, looks fine from a q
On 03/05/2013 10:46 PM, Waiman Long wrote:
On 03/05/2013 03:53 PM, Rik van Riel wrote:
Indeed. Though how well my patches will work with Oracle will
depend a lot on what kind of semctl syscalls they are doing.
Does Oracle typically do one semop per semctl syscall, or does
it pass in a whole
On 03/05/2013 03:53 PM, Rik van Riel wrote:
On 03/05/2013 03:52 PM, Linus Torvalds wrote:
On Tue, Mar 5, 2013 at 11:42 AM, Waiman Long wrote:
The recommended kernel.sem value from Oracle is "250 32000 100 128".
I have
tried to reduce the maximum semaphores per array (1st value) while
increa
On 03/05/2013 03:52 PM, Linus Torvalds wrote:
On Tue, Mar 5, 2013 at 11:42 AM, Waiman Long wrote:
The recommended kernel.sem value from Oracle is "250 32000 100 128". I have
tried to reduce the maximum semaphores per array (1st value) while
increasing the max number of arrays. That tends to re
On Tue, Mar 5, 2013 at 11:42 AM, Waiman Long wrote:
>
> The recommended kernel.sem value from Oracle is "250 32000 100 128". I have
> tried to reduce the maximum semaphores per array (1st value) while
> increasing the max number of arrays. That tends to reduce the ipc_lock
> contention in kernel,
On 03/05/2013 12:10 PM, Rik van Riel wrote:
On 03/05/2013 04:35 AM, Davidlohr Bueso wrote:
2) While on an Oracle swingbench DSS (data mining) workload the
improvements are not as exciting as with Rik's benchmark, we can see
some positive numbers. For an 8 socket machine the following are the
pe
On 03/05/2013 04:35 AM, Davidlohr Bueso wrote:
2) While on an Oracle swingbench DSS (data mining) workload the
improvements are not as exciting as with Rik's benchmark, we can see
some positive numbers. For an 8 socket machine the following are the
percentages of %sys time incurred in the ipc lo
On Tue, Mar 5, 2013 at 1:35 AM, Davidlohr Bueso wrote:
>
> The following set of patches are based on the discussion of holding the
> ipc lock unnecessarily, such as for permissions and security checks:
Ok, looks fine from a quick look (but then, so did your previous patch-set ;)
You still open-c
Hi,
The following set of patches are based on the discussion of holding the
ipc lock unnecessarily, such as for permissions and security checks:
https://lkml.org/lkml/2013/2/28/540
Patch 1/4: Remove the bogus comment from ipc_checkid() requiring that
the ipc lock be held before calling it. Also
15 matches
Mail list logo