On 04/06/2015 07:59 PM, Steven Rostedt wrote:
>
Thanks for the comments.
> Hmm, why is it not allowed?
>
> If we just let it boost it, it will cut down on the code changes and
> checks that add to the hot paths.
>
There is a WARN_ON() at line 3150 in sched/core.c to warn against
boosting id
This patch fixes the problem that the ownership of a mutex acquired by an
interrupt handler(IH) gets incorrectly attributed to the interrupted thread.
This could result in an incorrect deadlock detection in function
rt_mutex_adjust_prio_chain(), causing thread to be killed and possibly leading
up
ndler task value.
- Removed code to hadle the reserved interrupt handler's task value.
Thavatchai Makphaibulchoke (2):
rtmutex Real-Time Linux: Fixing kernel BUG at
kernel/locking/rtmutex.c:997!
kernel/locking/rtmutex.c: some code optimization
kernel/locking/rtmut
Adding the following code optimization,
- Reducing the number of cmpxchgs. Only call mark_rt_mutex_waiters() when
needed, waiters bit is not set.
- Reducing the hold time of wait_lock lock.
- Calling fixup_rt_mutex_waiters() only when needed.
- When unlocking rt_spin_lock in IRQ, alternate betw
On 03/22/2015 10:42 PM, Mike Galbraith wrote:
>> Why can't we just Let swapper be the owner when in irq with no dummy?
>>
Thanks Mike for the suggestion. That may also work. Unfortunately
somehow I'm still having a hung problem, which may be related to the
priority of the interrupt handler task
On 03/19/2015 10:26 AM, Steven Rostedt wrote:
> On Thu, 19 Mar 2015 09:17:09 +0100
> Mike Galbraith wrote:
>
>
>> (aw crap, let's go shopping)... so why is the one in timer.c ok?
>
> It's not. Sebastian, you said there were no other cases of rt_mutexes
> being taken in hard irq context. Looks
On 02/23/2015 11:37 AM, Steven Rostedt wrote:
>
> OK, I believe I understand the issue. Perhaps it would be much better
> to create a fake task per CPU that we use when grabbing locks in
> interrupt mode. And make these have a priority of 0 (highest), since
> they can not be preempted, they do h
On 02/19/2015 09:53 PM, Steven Rostedt wrote:
> On Thu, 19 Feb 2015 18:31:05 -0700
> Thavatchai Makphaibulchoke wrote:
>
>> This patch fixes the problem that the ownership of a mutex acquired by an
>> interrupt handler(IH) gets incorrectly attributed to the interrupte
Adding the following code optimization,
- Reducing the number of cmpxchgs. Only call mark_rt_mutex_waiters() when
needed, waiters bit is not set.
- Reducing the hold time of wait_lock lock.
- Calling fixup_rt_mutex_waiters() only when needed.
Signed-off-by: T. Makphaibulchoke
---
kernel/lock
This patch series compose of 2 patches.
First patch, fixing kernel BUG at kernel/locking/rtmutex.c:997!
Second patch, some code optimation in kernel/locking/rtmutex.c
Thavatchai Makphaibulchoke (2):
rtmutex Real-Time Linux: Fixing kernel BUG at
kernel/locking/rtmutex.c:997!
kernel
This patch fixes the problem that the ownership of a mutex acquired by an
interrupt handler(IH) gets incorrectly attributed to the interrupted thread.
This could result in an incorrect deadlock detection in function
rt_mutex_adjust_prio_chain(), causing thread to be killed and possibly leading
up
On 02/13/2015 12:19 PM, Paul Gortmaker wrote:
>
> I think there is more to this issue than just a lock conversion.
> Firstly, if we look at the existing -rt patches, we've got the old
> patch from ~2009 that is:
>
Thanks Paul for testing and reporting the problem.
Yes, looks like the issue pr
Since memory cgroups can be called from a page fault handler as shown
by the stack dump here,
[12679.513255] BUG: scheduling while atomic: ssh/10621/0x0002
[12679.513305] Preemption disabled at:[]
mem_cgroup_charge_common+0x37/0x60
[12679.513305]
[12679.513322] Call Trace:
[12679.513331] []
Since memory cgroups can be called from a page fault handler as shown
by the stack dump here,
[12679.513255] BUG: scheduling while atomic: ssh/10621/0x0002
[12679.513305] Preemption disabled at:[]
mem_cgroup_charge_common+0x37/0x60
[12679.513305]
[12679.513322] Call Trace:
[12679.513331] []
On 06/24/2014 04:03 PM, Maciej W. Rozycki wrote:
> On Thu, 3 Apr 2014, Theodore Ts'o wrote:
>
>> fs/mbcache.c: doucple the locking of local from global data
>
> This change causes breakage:
>
> fs/built-in.o: In function `__mb_cache_entry_release':
> mbcache.c:(.text+0x56b3c): undefined r
On 05/26/2014 11:04 PM, Randy Dunlap wrote:
> On 05/26/2014 11:17 AM, werner wrote:
> @tmac: can mbcache.c #include and use ilog2(NR_BG_LOCKS)
> instead of using __builtin_log2(NR_BG_LOCKS) ?
> (ref. commit ID 1f3e55fe02d12213f87869768aa2b0bad3ba9a7d)
>
I don't see any problem with that, unless
On 04/15/2014 11:25 AM, Jan Kara wrote:
> I have checked the source and I didn't find many places where i_mutex was
> not held. But maybe I'm wrong. That's why I wanted to see the patch where
> you are using i_mutex instead of hashed mutexes and which didn't perform
> good enough.
>
I've attach
On 04/14/2014 11:40 AM, Jan Kara wrote:
> Thanks for trying that out! Can you please send me a patch you have been
> testing? Because it doesn't quite make sense to me why using i_mutex should
> be worse than using hashed locks...
>
Thanks again for the comments.
Since i_mutex is also used for
On 04/02/2014 11:41 AM, Jan Kara wrote:
> Thanks for the patches and measurements! So I agree we contend a lot on
> orphan list changes in ext4. But what you do seems to be unnecessarily
> complicated and somewhat hiding the real substance of the patch. If I
> understand your patch correctly, all
On 04/02/2014 11:41 AM, Jan Kara wrote:
> Thanks for the patches and measurements! So I agree we contend a lot on
> orphan list changes in ext4. But what you do seems to be unnecessarily
> complicated and somewhat hiding the real substance of the patch. If I
> understand your patch correctly, all
On 01/24/2014 11:09 PM, Andreas Dilger wrote:
> I think the ext4 block groups are locked with the blockgroup_lock that has
> about the same number of locks as the number of cores, with a max of 128,
> IIRC. See blockgroup_lock.h.
>
> While there is some chance of contention, it is also unlikel
On 01/28/2014 02:09 PM, Andreas Dilger wrote:
> On Jan 28, 2014, at 5:26 AM, George Spelvin wrote:
>>> The third part of the patch further increases the scalablity of an ext4
>>> filesystem by having each ext4 fielsystem allocate and use its own private
>>> mbcache structure, instead of sharing a
On 01/24/2014 11:09 PM, Andreas Dilger wrote:
> I think the ext4 block groups are locked with the blockgroup_lock that has
> about the same number of locks as the number of cores, with a max of 128,
> IIRC. See blockgroup_lock.h.
>
> While there is some chance of contention, it is also unlikel
On 01/28/2014 02:09 PM, Andreas Dilger wrote:
> On Jan 28, 2014, at 5:26 AM, George Spelvin wrote:
>>> The third part of the patch further increases the scalablity of an ext4
>>> filesystem by having each ext4 fielsystem allocate and use its own private
>>> mbcache structure, instead of sharing a
On 01/24/2014 11:09 PM, Andreas Dilger wrote:
> I think the ext4 block groups are locked with the blockgroup_lock that has
> about the same number of locks as the number of cores, with a max of 128,
> IIRC. See blockgroup_lock.h.
>
> While there is some chance of contention, it is also unlikel
On 01/24/2014 02:38 PM, Andi Kleen wrote:
> T Makphaibulchoke writes:
>
>> The patch consists of three parts.
>>
>> The first part changes the implementation of both the block and hash chains
>> of
>> an mb_cache from list_head to hlist_bl_head and also introduces new members,
>> including a spi
On 10/30/2013 08:42 AM, Theodore Ts'o wrote:
> I tried running xfstests with this patch, and it blew up on
> generic/020 test:
>
> generic/020 [10:21:50][ 105.170352] [ cut here ]
> [ 105.171683] kernel BUG at
> /usr/projects/linux/ext4/include/linux/bit_spinlock.h:76!
On 10/03/2013 06:28 PM, Andreas Dilger wrote:
>
> It would also be possible to have a completely contention-free orphan
> inode list by only generating the on-disk orphan linked list in a
> pre-commit callback hook from an efficient in-memory list. That would
> allow the common "add to orphan lis
On 10/03/2013 06:37 PM, Andreas Dilger wrote:
> On 2013-10-02, at 9:36 AM, T Makphaibulchoke wrote:
>
> What do these additional fields do to the size of struct ext4_inode_info?
> I recall that Ted did a bunch of work to shrink this enough to fit nicely
> into a slab, and it would be a shame to in
On 10/03/2013 06:41 PM, Andreas Dilger wrote:
>> +struct inode *next_inode;
>
> Stack space in the kernel is not so abundant that all (or any?) of these
> should get their own local variable.
>
>>
>> -if (!EXT4_SB(sb)->s_journal)
>
> Same here.
>
>
> Cheers, Andreas
Thanks Andreas fo
On 10/02/2013 08:05 PM, Zheng Liu wrote:
> Hello,
>
>> -if (!EXT4_SB(sb)->s_journal)
>> +if (ext4_sb->s_journal)
>
> typo: !ext4_sb->s_journal
> I am not sure whether or not this will impact the result because when
> journal is enabled the inode will not be added
On 09/11/2013 09:25 PM, Theodore Ts'o wrote:
> On Wed, Sep 11, 2013 at 03:48:57PM -0500, Eric Sandeen wrote:
>>
>> So at this point I think it's up to Mak to figure out why on his system,
>> aim7 is triggering mbcache codepaths.
>>
>
> Yes, the next thing is to see if on his systems, whether or n
On 09/10/2013 09:02 PM, Theodore Ts'o wrote:
> On Tue, Sep 10, 2013 at 02:47:33PM -0600, Andreas Dilger wrote:
>> I agree that SELinux is enabled on enterprise distributions by default,
>> but I'm also interested to know how much overhead this imposes. I would
>> expect that writing large external
On 09/06/2013 05:10 AM, Andreas Dilger wrote:
> On 2013-09-05, at 3:49 AM, Thavatchai Makphaibulchoke wrote:
>> No, I did not do anything special, including changing an inode's size. I
>> just used the profile data, which indicated mb_cache module as one of the
>> bot
On 09/04/2013 08:00 PM, Andreas Dilger wrote:
>
> In the past, I've raised the question of whether mbcache is even
> useful on real-world systems. Essentially, this is providing a
> "deduplication" service for ext2/3/4 xattr blocks that are identical.
> The question is how often this is actually
On 09/05/2013 02:35 AM, Theodore Ts'o wrote:
> How did you gather these results? The mbcache is only used if you are
> using extended attributes, and only if the extended attributes don't
> fit in the inode's extra space.
>
> I checked aim7, and it doesn't do any extended attribute operations.
>
On 09/04/2013 08:00 PM, Andreas Dilger wrote:
>
> In the past, I've raised the question of whether mbcache is even
> useful on real-world systems. Essentially, this is providing a
> "deduplication" service for ext2/3/4 xattr blocks that are identical.
> The question is how often this is actually
Thanks for the comments.
On 08/22/2013 04:53 PM, Linus Torvalds wrote:
>
> Please don't do these ugly and pointless preprocessor macro expanders
> that hide what the actual operation is.
>
> The DEBUG case seems to be just for your own testing anyway, so even
> that shouldn't exist in the merged
On 07/18/2013 04:33 PM, Theodore Ts'o wrote:
> On Thu, Jul 18, 2013 at 12:30:24PM -0400, Theodore Ts'o wrote:
>> On Wed, Jul 17, 2013 at 06:55:10PM -0600, T Makphaibulchoke wrote:
>>> This patch intends to improve the scalability of an ext4 filesystem by
>>> introducing higher degree of parallelism
Thank you both for the comments.
Sounds like a better solution is to allow accesses to only I/O regions
presented in the EFI memory map for physical addresses below 1 MB.
Do we need to worry about the X checksum in the first MB on an EFI system?
Thanks,
Mak.
On 10/02/2012 11:15 PM, Matthew Ga
On 08/27/2012 10:30 PM, Ram Pai wrote:
> For example:
> if the region requested is 1 to 100, but 20-30 is already reserved, than
> the earlier behavior would reserve 1-20 and 30-100. With your
> patch, it will just reserve 1-20.
>
> RP
>
Thanks RP for pointing the problem. Sorry for missing par
41 matches
Mail list logo
