Since organization practices have been mentioned already, here are some general pointers about what's behind the technical terms and where the pitfalls are.
Should I keep my texture pages at 2000x2000 or make them 4000x4000 ?
Bigger texture page size leads to less compatibility, as older devices may not be able to handle them properly. This is mainly determined by the GPU. It's up to you, a bit of research regarding what supports which size and, in the best case, testing on actual target hardware, to determine where you should draw the line.
I final goal is my game to run fine on low end 4GB RAM integrated Intel video card.
Probably the most crucial thing to be aware of here is that 4GB RAM and an integrated graphics card doesn't mean that you have 4GB of video memory. How much of it is usable depends on the amount of memory that is shared with the graphics card, usually called shared memory for that reason.
Any such memory will need enough space to store your texture page twice while it's being used - once in RAM, once in the shared RAM that's used as VRAM - and that's on top of anything else that's running on your target device, such as the operating system, background services and other running programs.
The process of swapping texture pages in and out of VRAM is what's referred to as a "texture swap". It happens when the graphic you are attempting to draw is not located on the texture page that is currently loaded into VRAM, causing it to be overwritten with the right texture page before the graphic can be drawn. This process takes some time to complete, and it stalls the drawing process until it's completed. Texture swaps by themselves aren't exactly a sign of impending doom, and to a certain extent, they are normal, as it is not always possible to put everything on the same texture page (in which case you would have the lowest possible amount of swaps).
The real concern here are situations where the same texture pages are swapped in and out numerous times during a single frame - like when you have lots of instances of an object which draws multiple sprites, both of which are on different texture pages - this adds a lot of waiting time in between the actual drawing and can lead to performance issues. This is why you should organize texture pages based on roughly when they will be drawn, so that once a texture page is unloaded from VRAM, it won't need to be loaded again for the rest of the frame.
While all other texture pages won't be loaded into VRAM when not in use, they will be loaded into RAM - that is, unless you specifically load and unload them dynamically. Great care should be taken with that, however - dynamically loaded graphics take up more memory than static ones, and I doubt that the amount of graphics that could be loaded dynamically (and, therefore, the amount of graphics that would not need to be loaded all the time) would not be sufficient to make this method be worth it, and would actually increase memory usage rather than decreasing it.
Since you're dealing with a 32-bit application here, you're also subject to the
32-bit memory limitations - although I doubt this will make a difference on your hypothetical target machine, as it is more likely to hit the total memory limit of 4GB with all other RAM usage taken into account before it hits the 2GB limit for the application.
Here's an example about texture page organization: Imagine everything that needs to be drawn to your screen as a
color-by-number image.
One method to complete it is to pick up a crayon that corresponds to any color, provided that there are tiles left that need to be colored with it, and coloring all corresponding tiles. You first color all "1"s, "3"s and "7"s pink, then all "2"s, "4"s and "6"s purple... and so on.
Another method is starting in the top-left corner, which is a "1". You pick up the pink pencil and color the tile before moving on to the next tile, which is a "2". Therefore, you drop the pink pencil, pick up the purple one and color the tile. You move on to the next tile, which is a "1" again, so you drop the pink pencil, pick up the purple one and color the tile...
Coloring a tile takes a certain amount of time.
Dropping a pencil and picking up another takes a certain amount of time too.
Coloring a tile represents drawing a graphic.
All tiles marked with the same number are drawing instructions to the same graphic located on a specific texture page.
A color is a texture page.
Swapping pencils represents texture swaps.
Finally, imagine the color-by-number image to be a simple chess board pattern - that's a worst-case scenario for method 2 (which stands for unorganized texture pages) and no problem at all for method 1 (which represents organized texture pages). Depending on how long a texture swap takes, method 2 can potentially be multiple times slower than method 1.
I'd say the primary concern should be compatibility - if your game doesn't run on the target device at all, any optimization you perform will be useless. The best way to ensure this is to run it on the target device, or a device with comparable specs. Optimization comes after that, and again, the best way to check whether you have to optimize something is to run it on the target machine. If there is no noticeable lag and the profiler doesn't capture any suspicious performance drains, your time is better spent on further development than on micro-optimization.
