On Wed, Feb 24, 2021 at 05:02:09PM -0800, Ivan Babrou wrote:
> Hello,
>
> We started seeing allocation failures on procfs reads after
> commit 4bd6a7353ee1 "sysctl: Convert to iter interfaces".
https://lore.kernel.org/linux-fsdevel/6345270a2c1160b89dd5e6715461f388176899d1.1612972413.git.jo...@tox
On Tue, 27 Nov 2012, Bernd Schubert wrote:
> I'm just investigating why a user space program has a rather large VmSize, but
> small VmRSS size. Looking into /proc/$pid/smaps I notice several areas with an
> size of about 64MB, but otherwise that area is unused. So far I did not find a
> way how to
On Sunday, 23 September 2007 21:18, Christian P. Schmidt wrote:
> Rafael J. Wysocki wrote:
> > On Sunday, 23 September 2007 18:19, Christian P. Schmidt wrote:
> >> Rafael J. Wysocki wrote:
> >>> On Sunday, 23 September 2007 14:38, Christian P. Schmidt wrote:
> Rafael J. Wysocki wrote:
> >
Rafael J. Wysocki wrote:
> On Sunday, 23 September 2007 18:19, Christian P. Schmidt wrote:
>> Rafael J. Wysocki wrote:
>>> On Sunday, 23 September 2007 14:38, Christian P. Schmidt wrote:
Rafael J. Wysocki wrote:
> On Saturday, 22 September 2007 17:41, Christian P. Schmidt wrote:
>> Hi
On Sunday, 23 September 2007 18:19, Christian P. Schmidt wrote:
> Rafael J. Wysocki wrote:
> > On Sunday, 23 September 2007 14:38, Christian P. Schmidt wrote:
> >> Rafael J. Wysocki wrote:
> >>> On Saturday, 22 September 2007 17:41, Christian P. Schmidt wrote:
> Hi all,
>
> I'm havin
Rafael J. Wysocki wrote:
> On Sunday, 23 September 2007 14:38, Christian P. Schmidt wrote:
>> Rafael J. Wysocki wrote:
>>> On Saturday, 22 September 2007 17:41, Christian P. Schmidt wrote:
Hi all,
I'm having a strange problem, of course not reproducible. Sometimes
after a suspen
On Sunday, 23 September 2007 14:38, Christian P. Schmidt wrote:
> Rafael J. Wysocki wrote:
> > On Saturday, 22 September 2007 17:41, Christian P. Schmidt wrote:
> >> Hi all,
> >>
> >> I'm having a strange problem, of course not reproducible. Sometimes
> >> after a suspend (to ram) and resume cycle,
Rafael J. Wysocki wrote:
> On Saturday, 22 September 2007 17:41, Christian P. Schmidt wrote:
>> Hi all,
>>
>> I'm having a strange problem, of course not reproducible. Sometimes
>> after a suspend (to ram) and resume cycle, the kernel will try to free
>> all memory. This means, all running applicat
On Saturday, 22 September 2007 17:41, Christian P. Schmidt wrote:
> Hi all,
>
> I'm having a strange problem, of course not reproducible. Sometimes
> after a suspend (to ram) and resume cycle, the kernel will try to free
> all memory. This means, all running applications are flushed to swap (as
>
> My test machine is a Dell Precision 490 with dual 5140 processors and
> 3GB of RAM. If I reduced kMaxSize to (2048 * 2048 * 236) is works.
> However, I need to allocate an array of char that is (2048 * 2048 * 256)
> and maybe even as large at (2048 * 2048 * 512).
>
> Obviously I have enough phy
Brian D. McGrew a écrit :
Good evening gents!
I need some help in allocating memory and understanding how the system
allocates memory with physical versus virtual page tables. Please
consider the following snippet of code. Please, no wisecracks about bad
code; it was written in 30 seconds in h
Brian D. McGrew wrote:
Good evening gents!
I need some help in allocating memory and understanding how the system
allocates memory with physical versus virtual page tables. Please
consider the following snippet of code. Please, no wisecracks about bad
code; it was written in 30 seconds in hast
On Fri, 6 Apr 2001, Wayne Whitney wrote:
>
> As was pointed out to me in January, another solution for i386 would be to
> fix a maximum stack size and have the mmap() allocations grow downward
> from the "top" of the stack (3GB - max stack size). I'm not sure why that
> is not currently done.
I
> > note, though, that you *CAN* actually malloc a lot more than 1G: you
> > just have to avoid causing mmaps that chop your VM at
> > TASK_UNMAPPED_BASE:
>
> Neat trick. I didn't realize that you could avoid allocating the mmap()
> buffers for stdin and stdout.
noone ever said you had to use s
On Fri, 6 Apr 2001, Mark Hahn wrote:
> note, though, that you *CAN* actually malloc a lot more than 1G: you
> just have to avoid causing mmaps that chop your VM at
> TASK_UNMAPPED_BASE:
Neat trick. I didn't realize that you could avoid allocating the mmap()
buffers for stdin and stdout.
As was
> can get at most 2GB. Newer glibc's allow you to tune the definition
> of "small" via an environment variable.
eventually, perhaps libc will be smart enough to create
more arenas in mmaped space once sbrk fails. note, though,
that you *CAN* actually malloc a lot more than 1G: you just
have to
In mailing-lists.linux-kernel, you wrote:
> Essentially, the problem can be summarized to be that on a machine
> with ample ram (2G, 4G, etc), I am unable to malloc a gig if I ask
> for the memory in small ( <= 128k) chunks.
Take a look at this message by Szabolcs Szakacsits:
http://marc.t
On Fri, Apr 06, 2001 at 10:06:47AM -0400, [EMAIL PROTECTED] wrote:
> Essentially, the problem can be summarized to be that on a machine
> with ample ram (2G, 4G, etc), I am unable to malloc a gig if I ask
> for the memory in small ( <= 128k) chunks. I've enclosed some results
> and a lit
[Ivan Stepnikov]
> I tried to call getrlimit(). It shows only 2G available memory and
> there is no way to increase it.
Right. Architectural limit. There needs to be some room in the
address space for kernel stuff, I/O, etc -- in Linux at least, having
to play with your page tables every singl
In mailing-lists.linux-kernel, you wrote:
>I encountered with problem: one process can not allocate more then 2Gb of
>memory.
This is a problem that I have run into myself. I am no kernel expert,
but I think I understand how this issue. Here is how the standard
kernel maps the 4Gb 32-bit addr
20 matches
Mail list logo
