--
setecientos cincuenta mil dolares han sido depositados a usted de Western
Union. Envie su nombre, numero de telefono, direccion, ocupacion
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Fri, Aug 2, 2013 at 12:17 AM, Aneesh Kumar K.V
wrote:
> Hillf Danton writes:
>
>> On Wed, Jul 31, 2013 at 2:37 PM, Joonsoo Kim wrote:
>>> On Wed, Jul 31, 2013 at 02:21:38PM +0800, Hillf Danton wrote:
On Wed, Jul 31, 2013 at 12:41 PM, Joonsoo Kim
wrote:
> On Wed, Jul 31, 2013
On Sat, 3 August 2013 20:33:16 -0400, Theodore Ts'o wrote:
>
> P.P.S. At least in theory, nothing of what I've described here has to
> be ext4 specific. We could implement this in the VFS layer, at which
> point not only ext4 would benefit, but also btrfs, xfs, f2fs, etc.
Except for an inode
On Sat, Aug 3, 2013 at 6:08 PM, Dave Airlie wrote:
>
> Alex Deucher (1):
> drm/radeon: fix 64 bit divide in SI spm code
That code is stupid. You're asking for a 64-by-64 divide, when the
divisor is clearly an "int" (100 and 1000 respectively).
Why is it doing "div64_s64()" instead of the
On Fri, Jul 26, 2013 at 09:20:34AM -0400, Jörn Engel wrote:
>
> I don't think the e2compr patches are strictly necessary. They are a
> good option, but not the only one.
Sorry for not chiming in earlier; I've been travelling this past week,
and between that and a bunch of other things I've
From: "Kirill A. Shutemov"
For now, TRANSPARENT_HUGEPAGE_PAGECACHE is only implemented for x86_64.
Radix tree perload overhead can be significant on BASE_SMALL systems, so
let's add dependency on !BASE_SMALL.
/sys/kernel/mm/transparent_hugepage/page_cache is runtime knob for the
feature. It's
From: "Kirill A. Shutemov"
Dump page order to trace to be able to distinguish between small page
and huge page in page cache.
Signed-off-by: Kirill A. Shutemov
Acked-by: Dave Hansen
---
include/trace/events/filemap.h | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git
From: "Kirill A. Shutemov"
The patch adds new zone stat to count file transparent huge pages and
adjust related places.
For now we don't count mapped or dirty file thp pages separately.
The patch depends on patch
thp: account anon transparent huge pages into NR_ANON_PAGES
Signed-off-by:
From: "Kirill A. Shutemov"
Try to allocate huge page if flags has AOP_FLAG_TRANSHUGE.
If, for some reason, it's not possible allocate a huge page at this
possition, it returns NULL. Caller should take care of fallback to
small pages.
Signed-off-by: Kirill A. Shutemov
---
include/linux/fs.h |
From: "Kirill A. Shutemov"
We're going to add/remove a number of page cache entries at once. This
patch implements add_bdi_stat() which adjusts bdi stats by arbitrary
amount. It's required for batched page cache manipulations.
Signed-off-by: Kirill A. Shutemov
---
include/linux/backing-dev.h
From: "Kirill A. Shutemov"
Existing stats specify source of thp page: fault or collapse. We're
going allocate a new huge page with write(2) and read(2). It's nither
fault nor collapse.
Let's introduce new events for that.
Signed-off-by: Kirill A. Shutemov
---
Documentation/vm/transhuge.txt |
From: "Kirill A. Shutemov"
For huge page we add to radix tree HPAGE_CACHE_NR pages at once: head
page for the specified index and HPAGE_CACHE_NR-1 tail pages for
following indexes.
Signed-off-by: Kirill A. Shutemov
Acked-by: Dave Hansen
---
include/linux/huge_mm.h| 24
From: "Kirill A. Shutemov"
For tail pages we need to take two refcounters:
- ->_count for its head page;
- ->_mapcount for the tail page;
To protect against splitting we take compound lock and re-check that we
still have tail page before taking ->_mapcount reference.
If the page was split we
From: "Kirill A. Shutemov"
replace_page_cache_page() is only used by FUSE. It's unlikely that we
will support THP in FUSE page cache any soon.
Let's pospone implemetation of THP handling in replace_page_cache_page()
until any will use it. -EINVAL and WARN_ONCE() for now.
Signed-off-by: Kirill
From: "Kirill A. Shutemov"
I've noticed that we allocated unneeded page for cache on read beyond
i_size. Simple test case (I checked it on ramfs):
$ touch testfile
$ cat testfile
It triggers 'no_cached_page' code path in do_generic_file_read().
Looks like it's regression since commit a32ea1e.
From: "Kirill A. Shutemov"
The base scheme is the same as for anonymous pages, but we walk by
mapping->i_mmap rather then anon_vma->rb_root.
When we add a huge page to page cache we take only reference to head
page, but on split we need to take addition reference to all tail pages
since they
From: "Kirill A. Shutemov"
This is the second part of my transparent huge page cache work.
It brings thp support for ramfs, but without mmap() -- it will be posted
separately.
Intro
-
The goal of the project is preparing kernel infrastructure to handle huge
pages in page cache.
To proof
From: "Kirill A. Shutemov"
simple_thp_release() is a dummy implementation of fops->release with
transparent huge page support. It's required to minimize memory overhead
of huge pages for small files.
It checks whether we should split the last page in the file to give
memory back to the system.
From: "Kirill A. Shutemov"
truncate_inode_pages_range() drops whole huge page at once if it's fully
inside the range.
If a huge page is only partly in the range we zero out the part,
exactly like we do for partial small pages.
invalidate_mapping_pages() just skips huge pages if they are not
From: "Kirill A. Shutemov"
We're going to have huge pages backed by files, so we need to modify
wait_split_huge_page() to support that.
We have two options for:
- check whether the page anon or not and serialize only over required
lock;
- always serialize over both locks;
Current
From: "Kirill A. Shutemov"
We are not ready to mmap file-backed tranparent huge pages. Let's split
them on fault attempt.
Later we'll implement mmap() properly and this code path be used for
fallback cases.
Signed-off-by: Kirill A. Shutemov
---
mm/filemap.c | 2 ++
1 file changed, 2
From: "Kirill A. Shutemov"
If a transhuge page is already in page cache (up to date and not
readahead) we go usual path: read from relevant subpage (head or tail).
If page is not cached (sparse file in ramfs case) and the mapping can
have hugepage we try allocate a new one and read it.
If a
From: "Kirill A. Shutemov"
simple_readpage() and simple_write_end() are modified to handle huge
pages.
simple_thp_write_begin() is introduced to allocate huge pages on write.
Signed-off-by: Kirill A. Shutemov
---
fs/libfs.c | 53 +
From: "Kirill A. Shutemov"
ramfs is the most simple fs from page cache point of view. Let's start
transparent huge page cache enabling here.
ramfs pages are not movable[1] and switching to transhuge pages doesn't
affect that. We need to fix this eventually.
[1]
From: "Kirill A. Shutemov"
Returns true if mapping can have huge pages. Just check for __GFP_COMP
in gfp mask of the mapping for now.
Signed-off-by: Kirill A. Shutemov
---
include/linux/pagemap.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/include/linux/pagemap.h
From: "Kirill A. Shutemov"
mem_cgroup_cache_charge() has check for PageCompound(). The check
prevents charging huge cache pages.
I don't see a reason why the check is present. Looks like it's just
legacy (introduced in 52d4b9a memcg: allocate all page_cgroup at boot).
Let's just drop it.
From: "Kirill A. Shutemov"
For now we still write/read at most PAGE_CACHE_SIZE bytes a time.
This implementation doesn't cover address spaces with backing storage.
Signed-off-by: Kirill A. Shutemov
---
mm/filemap.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git
From: "Kirill A. Shutemov"
As with add_to_page_cache_locked() we handle HPAGE_CACHE_NR pages a
time.
Signed-off-by: Kirill A. Shutemov
---
mm/filemap.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/mm/filemap.c b/mm/filemap.c
index 619e6cb..b75bdf5
From: "Kirill A. Shutemov"
The radix tree is variable-height, so an insert operation not only has
to build the branch to its corresponding item, it also has to build the
branch to existing items if the size has to be increased (by
radix_tree_extend).
The worst case is a zero height tree with
On Fri, Aug 02, 2013 at 02:03:46PM +0200, Piotr Sarna wrote:
> Commit 26092bf ("ext4: use a table-driven handler for mount options")
> introduced buggy handling of nodelalloc parameter in mount command.
>
> After explicitly using delalloc or nodelalloc parameter in mount command,
> MOPT_EXPLICIT
On Sun, Aug 4, 2013 at 6:20 AM, Felipe Contreras
wrote:
> On Sat, Aug 3, 2013 at 4:40 PM, Rafael J. Wysocki wrote:
>> On Saturday, August 03, 2013 03:24:16 PM Felipe Contreras wrote:
>>> On Sat, Aug 3, 2013 at 6:34 AM, Rafael J. Wysocki wrote:
>>> > On Saturday, August 03, 2013 04:14:04 PM
On Mon, Jul 15, 2013 at 12:14:18PM +0530, Nitin Singla wrote:
> -sbi->s_itb_per_group = sbi->s_inodes_per_group /
> -sbi->s_inodes_per_block;
> +sbi->s_itb_per_group = DIV_ROUND_UP(sbi->s_inodes_per_group,
> +sbi->s_inodes_per_block);
This would
The code to check whether num_regulator is valid is wrong because it should
iterate all array entries rather than break from the for loop if
pdata->regulators[i] is NULL.
Signed-off-by: Axel Lin
---
drivers/regulator/88pm800.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff
On 08/03/2013 07:34 PM, Rafael J. Wysocki wrote:
> On Saturday, August 03, 2013 04:14:04 PM Aaron Lu wrote:
>> On 08/03/2013 07:47 AM, Rafael J. Wysocki wrote:
>>> On Friday, August 02, 2013 02:37:09 PM Felipe Contreras wrote:
If the _BCL package is descending, the first level (br->levels[2])
DT Maintainers,
It's been a week with no comment. Shall I assume it's ok to apply
this?
thx,
Jason.
On Thu, Jul 25, 2013 at 11:31:04AM -0400, Jason Cooper wrote:
> On Tue, Jul 02, 2013 at 12:54:12PM +0200, Sebastian Hesselbarth wrote:
> > DMA_MEMSET support has been removed, so update the
Hi Linus,
just a quick fix that a few people have reported, be nice to have in asap.
Dave.
The following changes since commit 72a67a94bcba71a5fddd6b3596a20604d2b5dcd6:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2013-08-03
15:00:23 -0700)
are available in the git
On Sat, 2013-08-03 at 03:01 +0200, Rafael J. Wysocki wrote:
> On Friday, August 02, 2013 06:04:40 PM Toshi Kani wrote:
> > On Sat, 2013-08-03 at 01:43 +0200, Rafael J. Wysocki wrote:
> > > On Friday, August 02, 2013 03:46:15 PM Toshi Kani wrote:
> > > > On Thu, 2013-08-01 at 23:43 +0200, Rafael J.
On Sat, 2013-08-03 at 02:47 +0200, Rafael J. Wysocki wrote:
> On Friday, August 02, 2013 04:38:38 PM Toshi Kani wrote:
> > On Fri, 2013-08-02 at 00:33 +0200, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki
> > >
> > > Modify acpi_bind_one() so that it doesn't fail if the device
> > >
On Sat, Aug 3, 2013 at 6:27 PM, Igor Gnatenko
wrote:
> On Sat, 2013-08-03 at 15:21 -0500, Felipe Contreras wrote:
>> On Sat, Aug 3, 2013 at 11:08 AM, Igor Gnatenko
>> wrote:
>>
>> > I am opposed to this patch. On ThinkPad X230 I had problems with it.
>> > Felipe, come over to dark side. They
* Vern Clark (vmcl...@verizon.net) wrote:
>
> Plugging in any USB flash stick takes 5-6 minutes before its mounted.
>
> ===
> Using the current kernel-3.8.0-28-generic, the USB fails to load in proper
> time.
> I found this message in syslog: timeout: killing '/sbin/blkid -o udev -p
>
On Thu, Aug 1, 2013 at 4:36 AM, Rich Felker wrote:
> On Thu, Aug 01, 2013 at 01:29:51AM -0700, Christoph Hellwig wrote:
>> Btw, FreeBSD has an extension to shm_open to create unnamed but fd
>> passable segments. From their man page:
>>
>> As a FreeBSD extension, the constant SHM_ANON may be
On Sat, 2013-08-03 at 15:21 -0500, Felipe Contreras wrote:
> On Sat, Aug 3, 2013 at 11:08 AM, Igor Gnatenko
> wrote:
>
> > I am opposed to this patch. On ThinkPad X230 I had problems with it.
> > Felipe, come over to dark side. They have cookies.
>
> And v3.11-rc3 works's fine out-of-the box?
>
On Sat, Aug 03, 2013 at 02:38:45PM -0700, Andres Salomon wrote:
> On Sat, 3 Aug 2013 23:36:15 +0200
> Jens Frederich wrote:
>
> > On Sat, Aug 3, 2013 at 11:16 PM, Andres Salomon
> > wrote:
> > > Please Cc Daniel on these. Cjb and myself are no longer at olpc.
> > >
> >
> > Do you know what's
On Sat, Aug 03, 2013 at 10:44:35PM +0200, Jens Frederich wrote:
> @@ -126,7 +127,7 @@ static int dcon_bus_stabilize(struct dcon_priv *dcon, int
> is_powered_down)
> power_up:
> if (is_powered_down) {
> x = 1;
> - x = olpc_ec_cmd(0x26, (unsigned char *), 1, NULL,
On Sat, Aug 03, 2013 at 07:02:50AM -0700, Guenter Roeck wrote:
> On 08/02/2013 03:07 AM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.10.5 release.
> >There are 99 patches in this series, all will be posted as a response
> >to this one. If anyone has any
On Sat, Aug 3, 2013 at 5:38 PM, Rafael J. Wysocki wrote:
> On Saturday, August 03, 2013 05:20:33 PM Felipe Contreras wrote:
>> On Sat, Aug 3, 2013 at 4:40 PM, Rafael J. Wysocki wrote:
>> > On Saturday, August 03, 2013 03:24:16 PM Felipe Contreras wrote:
>> >> On Sat, Aug 3, 2013 at 6:34 AM,
On Thu, 1 Aug 2013, Ulrich Windl wrote:
> Hi folks!
>
> I think I'd let you know (maybe I'm wrong, and the kernel is right):
>
> I write a C-program that maps a file into an private writable map. Then I
> modify the area a bit and use one write to write that area back to a file.
>
> This
On Fri, Aug 02, 2013 at 06:19:19PM -0700, Bob Smith wrote:
> This character device can give daemons an interface similar to
> the kernel's /sys and /proc interfaces. It is a nice way to
> give user space drivers real device nodes in /dev.
Other comments about this patch:
> From
On Sat, Aug 3, 2013 at 5:21 PM, Rafael J. Wysocki wrote:
> On Saturday, August 03, 2013 05:06:10 PM Felipe Contreras wrote:
>> On Sat, Aug 3, 2013 at 4:59 PM, Rafael J. Wysocki wrote:
>
> [...]
>
>> > Whatever you are thinking you will achieve this way, it doesn't work.
>>
>> It is the reality:
On Saturday, August 03, 2013 05:20:33 PM Felipe Contreras wrote:
> On Sat, Aug 3, 2013 at 4:40 PM, Rafael J. Wysocki wrote:
> > On Saturday, August 03, 2013 03:24:16 PM Felipe Contreras wrote:
> >> On Sat, Aug 3, 2013 at 6:34 AM, Rafael J. Wysocki wrote:
> >> > On Saturday, August 03, 2013
On Wed, Jul 31, 2013 at 08:18:06AM +0200, Jean-Francois Moine wrote:
> To avoid the declaration of a 'kirkwood-pcm-audio' device in the DT,
> this patch merges the kirkwood-i2c and kirkwood-dma drivers into one
> module associated with 'kirkwood-i2s'.
I suggest holding off on this stuff at the
On Sat, Aug 3, 2013 at 4:40 PM, Rafael J. Wysocki wrote:
> On Saturday, August 03, 2013 03:24:16 PM Felipe Contreras wrote:
>> On Sat, Aug 3, 2013 at 6:34 AM, Rafael J. Wysocki wrote:
>> > On Saturday, August 03, 2013 04:14:04 PM Aaron Lu wrote:
>>
>> >> Yes, the patch is correct, but I still
On Saturday, August 03, 2013 05:06:10 PM Felipe Contreras wrote:
> On Sat, Aug 3, 2013 at 4:59 PM, Rafael J. Wysocki wrote:
[...]
> > Whatever you are thinking you will achieve this way, it doesn't work.
>
> It is the reality: v3.7 is broken, v3.8 is broken, v3.9 is broken,
> v3.10 is broken,
On Sat, Aug 3, 2013 at 4:59 PM, Rafael J. Wysocki wrote:
> On Saturday, August 03, 2013 03:20:22 PM Felipe Contreras wrote:
>> On Sat, Aug 3, 2013 at 6:54 AM, Rafael J. Wysocki wrote:
>> > On Friday, August 02, 2013 08:48:09 PM Felipe Contreras wrote:
>>
>> >> Yes, that's fine, either the
On Saturday, August 03, 2013 06:57:11 PM Viresh Kumar wrote:
> On 3 August 2013 17:38, Rafael J. Wysocki wrote:
> > On Saturday, August 03, 2013 05:19:26 PM Viresh Kumar wrote:
> >> Governor's owner refcount usage was broken. We should increment refcount
> >> only
> >> when
On Saturday, August 03, 2013 06:58:35 PM Viresh Kumar wrote:
> On 3 August 2013 17:37, Rafael J. Wysocki wrote:
> > On Saturday, August 03, 2013 05:19:18 PM Viresh Kumar wrote:
> >> Hi Rafael,
> >>
> >> This patchset tries to fix & cleanup many existing cpufreq core issues.
> >> First
> >> four
On Saturday, August 03, 2013 03:20:22 PM Felipe Contreras wrote:
> On Sat, Aug 3, 2013 at 6:54 AM, Rafael J. Wysocki wrote:
> > On Friday, August 02, 2013 08:48:09 PM Felipe Contreras wrote:
>
> >> Yes, that's fine, either the revert, or the patch I mentioned, or
> >> something else, but
On Sat, 3 Aug 2013 23:36:15 +0200
Jens Frederich wrote:
> On Sat, Aug 3, 2013 at 11:16 PM, Andres Salomon
> wrote:
> > Please Cc Daniel on these. Cjb and myself are no longer at olpc.
> >
>
> Do you know what's with Jon Nettleton? He is also on the TODO list?
Let's ask. Jon, do you still
On Sat, Aug 3, 2013 at 11:16 PM, Andres Salomon wrote:
> Please Cc Daniel on these. Cjb and myself are no longer at olpc.
>
Do you know what's with Jon Nettleton? He is also on the TODO list?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Saturday, August 03, 2013 10:43:45 PM Viresh Kumar wrote:
> On 3 August 2013 17:19, Viresh Kumar wrote:
> > They are pretty much mixed up. Although generic headers are present but
> > definitions/declarations are present outside them too..
> >
> > This patch just moves stuff up and down to
On Saturday, August 03, 2013 10:45:04 PM Viresh Kumar wrote:
> On 3 August 2013 17:19, Viresh Kumar wrote:
> > This patch intends to cleanup following issues in the header files included
> > in
> > cpufreq core layers:
> > - Include headers in ascending order, so that we don't add same multiple
On Sat, Aug 3, 2013 at 11:16 PM, Andres Salomon wrote:
> Please Cc Daniel on these. Cjb and myself are no longer at olpc.
>
Sorry, I've forgotten it. I will update the the TODO list.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Saturday, August 03, 2013 03:24:16 PM Felipe Contreras wrote:
> On Sat, Aug 3, 2013 at 6:34 AM, Rafael J. Wysocki wrote:
> > On Saturday, August 03, 2013 04:14:04 PM Aaron Lu wrote:
>
> >> Yes, the patch is correct, but I still prefer my own version :-)
> >>
Please Cc Daniel on these. Cjb and myself are no longer at olpc.
On Sat, 3 Aug 2013 22:44:35 +0200
Jens Frederich wrote:
> This patch replace some magic numbers. I believe it makes
> the driver more readable.
>
> The magic number 0x26 is the XO system embedded controller
> (EC) command
The TODO entry - drop global variables, use a proper olpc_dcon_priv
struct - is already finished. The driver has no global variables.
It uses the private structure 'dcon_priv'.
Signed-off-by: Jens Frederich
diff --git a/drivers/staging/olpc_dcon/TODO b/drivers/staging/olpc_dcon/TODO
index
This patch replace some magic numbers. I believe it makes
the driver more readable.
The magic number 0x26 is the XO system embedded controller
(EC) command 'DCON power enable/disable'.
Number 0x41, and 0x42 are special memory controller settings
register. The 0x41 initialize bit sequence 0x101
From: Aaro Koskinen
Date: Mon, 17 Jun 2013 08:58:39 +0300
> On Mon, Jun 17, 2013 at 08:32:25AM +0300, Aaro Koskinen wrote:
>> On Mon, Jun 17, 2013 at 12:06:00AM +0300, Meelis Roos wrote:
>> > Got this in 3.10-rc6 whil testing debian unstable upgrade with aptitude.
>> > 3.10-rc5 did not exhibit
On Sat, Aug 3, 2013 at 6:38 AM, Rafael J. Wysocki wrote:
> On Friday, August 02, 2013 08:34:29 PM Felipe Contreras wrote:
>> On Fri, Aug 2, 2013 at 7:07 PM, Rafael J. Wysocki wrote:
>> > On Friday, August 02, 2013 12:52:18 PM Felipe Contreras wrote:
>> >> On Fri, Aug 2, 2013 at 9:05 AM, Rafael
On Sat, Aug 3, 2013 at 6:34 AM, Rafael J. Wysocki wrote:
> On Saturday, August 03, 2013 04:14:04 PM Aaron Lu wrote:
>> Yes, the patch is correct, but I still prefer my own version :-)
>> https://github.com/aaronlu/linux/commit/0a3d2c5b59caf80ae5bb1ca1fda0f7bf448b38c9
>>
>> In case you want to
On Sat, Aug 3, 2013 at 11:08 AM, Igor Gnatenko
wrote:
> I am opposed to this patch. On ThinkPad X230 I had problems with it.
> Felipe, come over to dark side. They have cookies.
And v3.11-rc3 works's fine out-of-the box?
--
Felipe Contreras
--
To unsubscribe from this list: send the line
On Sat, Aug 3, 2013 at 6:54 AM, Rafael J. Wysocki wrote:
> On Friday, August 02, 2013 08:48:09 PM Felipe Contreras wrote:
>> Yes, that's fine, either the revert, or the patch I mentioned, or
>> something else, but something has to be done, and it was better to do
>> it in v3.11-rc4 than in
>>> You missed the "!". I'm proposing that setting the new bit 2 will
>>> permit people to prevent the new printk if it is causing them problems.
>>
>> No I don't. I'm sure almost all abuse users think our usage is correct. Then,
>> I can imagine all crazy applications start to use this flag
On Fri, Aug 02, 2013 at 12:44:26PM -0500, Nathan Zimmer wrote:
> Currently we when we initialze each page struct is set as reserved upon
> initialization. This changes to starting with the reserved bit clear and
> then only setting the bit in the reserved region.
>
> I could restruture a bit to
1) Don't ignore user initiated wireless regulatory settings on cards
with custom regulatory domains, from Arik Nemtsov.
2) Fix length check of bluetooth information responses, from Jaganath
Kanakkassery.
3) Fix misuse of PTR_ERR in btusb, from Adam Lee.
4) Handle rfkill properly while
On 31/07/2013 8:46 p.m., Arnaldo Carvalho de Melo wrote:
Em Wed, Jul 31, 2013 at 02:28:33PM -0300, Arnaldo Carvalho de Melo escreveu:
Still investigating, but the attached patch is needed to handle such
failure cases:
[root@zoo ~]# perf test 21
21: Test object code reading
On Fri, Aug 2, 2013 at 1:34 PM, Alex Thorlton wrote:
>> What kind of workloads are you talking about?
>
> Our benchmarking team has a list of several of the SPEC OMP benchmarks
> that perform significantly better when THP is disabled. I tried to get
> the list but one of our servers is acting up
On Sat, Aug 3, 2013 at 11:55 AM, Oleg Nesterov wrote:
> On 08/03, Kees Cook wrote:
>>
>> On Thu, Aug 1, 2013 at 12:05 PM, Oleg Nesterov wrote:
>> > Nobody except search_binary_handler() should touch ->recursion_depth,
>> > "int depth" buys nothing but complicates the code, kill it.
>>
>> I'd
On Fri, Aug 2, 2013 at 12:27 PM, Oleg Nesterov wrote:
> On top of "[PATCH 0/3] exec: minor cleanups + minor fix" I sent
> yesterday.
>
> Perhaps too many patches for the poor search_binary_handler(),
> but I do not know how to document the changes if I join them.
>
> Oleg.
>
> fs/exec.c | 82
On Fri, Aug 2, 2013 at 12:27 PM, Oleg Nesterov wrote:
> When search_binary_handler() succeeds it does allow_write_access()
> and fput(), then it clears bprm->file to ensure the caller will not
> do the same.
>
> We can simply move this code to exec_binprm() which is called only
> once. In fact we
On 2/08/2013 4:33 p.m., Jiri Olsa wrote:
The perf compilation fails with following error:
...
CC arch/x86/util/tsc.o
arch/x86/util/tsc.c: In function ‘perf_time_to_tsc’:
arch/x86/util/tsc.c:13:6: error: declaration of ‘time’ shadows a global
declaration [-Werror=shadow]
On Thu, Aug 1, 2013 at 12:05 PM, Oleg Nesterov wrote:
> A separate one-liner with the minor fix.
>
> PROC_EVENT_EXEC reports the "exec" event, but this message
> is sent at least twice if search_binary_handler() is called
> by ->load_binary() recursively, say, load_script().
>
> Move it to
On Thu, Aug 1, 2013 at 12:05 PM, Oleg Nesterov wrote:
> task_pid_nr_ns() and trace/ptrace code in the middle of the
> recursive search_binary_handler() looks confusing and imho
> annoying. We only need this code if "depth == 0", lets add
> a simple helper which calls search_binary_handler() and
On 08/03, Kees Cook wrote:
>
> On Thu, Aug 1, 2013 at 12:05 PM, Oleg Nesterov wrote:
> > Nobody except search_binary_handler() should touch ->recursion_depth,
> > "int depth" buys nothing but complicates the code, kill it.
>
> I'd like to see a comment added to binfmts.h's recursion_depth field
>
On Thu, Aug 1, 2013 at 12:05 PM, Oleg Nesterov wrote:
> Nobody except search_binary_handler() should touch ->recursion_depth,
> "int depth" buys nothing but complicates the code, kill it.
I'd like to see a comment added to binfmts.h's recursion_depth field
that reminds people that
Greg
Thanks for your reply. I'll reply to your comments in reverse order.
Greg Kroah-Hartman wrote:
And how does this have anything to do with /sys? I can't see any sysfs
interaction in the code, or am I missing it?
Yes, you are right. I'll change the subject and brief descriptions to
On Mon, Jul 29, 2013 at 02:29:02PM +0200, Sebastian Hesselbarth wrote:
> This patch set comprises some DT updates and cleanup patches that
> piled up in the past. The first patch adds a cpu node for the
> Marvell Sheeva PJ4(A) CPU found on Dove SoCs. While touching the
> dtsi, also some nodes are
ARM Performance Monitor Units are available on the am33xx, add the support in
the dtsi.
Tested with perf and oprofile on a regular beaglebone.
Signed-off-by: Alexandre Belloni
---
arch/arm/boot/dts/am33xx.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git
On 3 August 2013 17:19, Viresh Kumar wrote:
> This patch intends to cleanup following issues in the header files included in
> cpufreq core layers:
> - Include headers in ascending order, so that we don't add same multiple times
> by mistake.
> - must be included after , so that they override
On 3 August 2013 17:19, Viresh Kumar wrote:
> They are pretty much mixed up. Although generic headers are present but
> definitions/declarations are present outside them too..
>
> This patch just moves stuff up and down to make it look better and consistent.
>
> Signed-off-by: Viresh Kumar
> ---
Hi azur,
here is the x86-only rollup of the series for 3.2.
Thanks!
Johannes
---
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 5db0490..314fe53 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -842,30 +842,22 @@ do_sigbus(struct pt_regs *regs, unsigned long
On 08/02, Alex Thorlton wrote:
>
> This patch implements functionality to allow processes to disable the use of
> transparent hugepages through the prctl syscall.
>
> We've determined that some jobs perform significantly better with thp
> disabled,
> and we needed a way to control thp on a
Changes in version 2:
o use user_mode() instead of open coding it on s390 (Heiko Carstens)
o clean up memcg OOM enable/disable toggling (Michal Hocko & KOSAKI
Motohiro)
o add a separate patch to rework and document OOM locking
o fix a problem with lost wakeups when sleeping on the OOM lock
o fix
Unlike global OOM handling, memory cgroup code will invoke the OOM
killer in any OOM situation because it has no way of telling faults
occuring in kernel context - which could be handled more gracefully -
from user-triggered faults.
Pass a flag that identifies faults originating in user space
System calls and kernel faults (uaccess, gup) can handle an out of
memory situation gracefully and just return -ENOMEM.
Enable the memcg OOM killer only for user faults, where it's really
the only option available.
Signed-off-by: Johannes Weiner
---
include/linux/memcontrol.h | 44
Back before smart OOM killing, when faulting tasks where killed
directly on allocation failures, the arch-specific fault handlers
needed special protection for the init process.
Now that all fault handlers call into the generic OOM killer (609838c
"mm: invoke oom-killer from remaining unconverted
The memcg OOM handler open-codes a sleeping lock for OOM serialization
(trylock, wait, repeat) because the required locking is so specific to
memcg hierarchies. However, it would be nice if this construct would
be clearly recognizable and not be as obfuscated as it is right now.
Clean up as
Kernel faults are expected to handle OOM conditions gracefully (gup,
uaccess etc.), so they should never invoke the OOM killer. Reserve
this for faults triggered in user context when it is the only option.
Most architectures already do this, fix up the remaining few.
Signed-off-by: Johannes
The memcg OOM handling is incredibly fragile and can deadlock. When a
task fails to charge memory, it invokes the OOM killer and loops right
there in the charge code until it succeeds. Comparably, any other
task that enters the charge path at this point will go to a waitqueue
right then and
The x86 fault handler bails in the middle of error handling when the
task has a fatal signal pending. For a subsequent patch this is a
problem in OOM situations because it relies on
pagefault_out_of_memory() being called even when the task has been
killed, to perform proper per-task OOM state
On 08/02, Zach Levis wrote:
>
> Obligatory first-patchset whitespace commit
Looks good, perhaps you send it as 1/3 or even separately, so you
won't need to redo it if you need to update 1-2.
> @@ -63,11 +63,11 @@ static int load_em86(struct linux_binprm *bprm)
>*/
>
1 - 100 of 348 matches
Mail list logo
