Value of TASK_UNMAPPED_SIZE on 2.4

All,

TASK_UNMAPPED_SIZE is defined in include/asm-i386/processor.h as:

#define TASK_UNMAPPED_SIZE (TASK_SIZE / 3)

The value of TASK_SIZE is defined as PAGE_OFFSET which is set to 0xC0000000 (page.h). This works out to be a value of 0x4000000.

The question is:
Are there any negative side effects in defining TASK_UNMAPPED_SIZE to 0x1000000?

By doing this we allow a process to access more memory. On Oracle it allows us to grow our buffer size from 1.7 GB to 2.4 GB improving overall performance by reducing I/O.

Thanks in advance,

--
=======================================================================

  Josue Emmanuel Amaro                         [email protected]
  Linux Products Manager                       Phone:   650.506.1239
  Intel and Linux Technologies Group           Fax:     650.413.0167

=======================================================================

begin:vcard
n:Amaro;Josue Emmanuel
tel;cell:650-245-5131
tel;fax:650-413-0167
tel;work:650-506-1239
x-mozilla-html:FALSE
url:http://www.oracle.com
org:Intel and Linux Technologies
version:2.1
email;internet:[email protected]
title:Sr.Product Manager - Linux
adr;quoted-printable:;;500 Oracle Parkway=0D=0AMS1ip4;Redwood Shores;CA;94065;United States fn:Josue Emmanuel Amaro
end:vcard

^ one more zero here

I guess you mean 0x10000000. There's no risk in doing that. I also did another patch that moves the kernel away and allows 3.5G per process on IA32 via plain mmap or shmat, but it has the downside of reducing a lot the ZONE_NORMAL where on IA32 buffercache and skb still lives.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

All,

Additional follow up.

The idea of modifying this variable is to increase the amount of memory that a process can use. A database like Oracle can benefit from this because it allows Oracle to create a bigger data buffer.

An obvious side effect of allocating more physical memory to a process is that there is less available for other things like the kernel buffer cache. This brings up a question. Would a write of a data block from the Oracle data buffer incur a "read penalty" if the block is not in the buffer cache?

For example, a data block is read by Oracle into its buffer. Since it is read through the file system, this block is now present in the buffer cache too. After a while, and since we have allocated most of the memory to Oracle, that block is removed/replaced from the cache.

Now a transaction modifies that block in Oracle's buffer and Oracle writes it to disk. Does the kernel firsts reads that block into the buffer cache, "read penalty", and then writes it to disk? Or does it just write through the buffer cache now placing the block in the kernel buffer cache?

Regards,

--
=======================================================================

  Josue Emmanuel Amaro                         [email protected]
  Linux Products Manager                       Phone:   650.506.1239
  Intel and Linux Technologies Group           Fax:     650.413.0167

=======================================================================

begin:vcard
n:Amaro;Josue Emmanuel
tel;cell:650-245-5131
tel;fax:650-413-0167
tel;work:650-506-1239
x-mozilla-html:FALSE
url:http://www.oracle.com
org:Intel and Linux Technologies
version:2.1
email;internet:[email protected]
title:Sr.Product Manager - Linux
adr;quoted-printable:;;500 Oracle Parkway=0D=0AMS1ip4;Redwood Shores;CA;94065;United States fn:Josue Emmanuel Amaro
end:vcard